Обсуждение: embeded tomcat and correct DataSource.

Asking for confirmation that, when using an embedded tomcat instance, I should use the PGConnectionPoolDataSource if I wish to use Apache connection pool mechanism.

 

I haven't setup an embedded tomcat in a while. I'd like to know the answer as well.

Any reason you aren't using something like quarkus ?

Dave Cramer

www.postgres.rocks

On Mon, 16 Nov 2020 at 12:05, Rob Sargent <robjsargent@gmail.com> wrote:

Asking for confirmation that, when using an embedded tomcat instance, I should use the PGConnectionPoolDataSource if I wish to use Apache connection pool mechanism.

 

Well I was just shooting for the shortest stack possible.   This is a home-grown server doing a very specific task, very specific clients (science stuff, neither Sir Elton nor I understand) My current working version has me managing a bare socket with a Selector.  But there are a couple of brittle parts there so a dear friend (still laughing up his sleeve I'm sure) suggested embedding tomcat to leverage their selector impl and http support.  Tests using DriverManager are working, now I think my last hurdle to using a DataSource is a jOOQ/java date/time issue.  I'm not at all sure I've wired the DataSource in correctly, but examples using embedded tomcat are rare as hen's teeth.

On Tue, 17 Nov 2020 at 17:57, Rob Bygrave <robin.bygrave@gmail.com> wrote:

Hi,

Sorry I'm probably mis-interpreting your question.  Hopefully the comments below are useful.

> I should use the PGConnectionPoolDataSource if I wish to use Apache connection pool mechanism.

In short, I'm pretty sure the answer is no.

The longer answer is, PGPoolingDataSource is the DataSource implementation provided in pgjdbc. PGPoolingDataSource is deprecated with the comment below and noting that PGPoolingDataSource uses PGConnectionPoolDataSource (as an implementation detail).  We could think of PGConnectionPoolDataSource as part of the DataSource implementation provided with postgresql jdbc driver that is marked as deprecated (with the suggestion that we migrate to any other third party DataSource implementation). 

* @deprecated Since 42.0.0, instead of this class you should use a fully featured connection pool

* like HikariCP, vibur-dbcp, commons-dbcp, c3p0, etc.

 

Any third party javax.sql.DataSource implementation would be extremely unlikely to use anything in the org.postgresql.ds package including PGConnectionPoolDataSource.

Rob,

Thanks for catching this. I mis-read the question.

Rob is correct! Do not use the PGPooling source for anything. It is really there for completeness. There are so many other good pooling implementations it just does not make sense for us to re-implement one.

 

Dave Cramer

www.postgres.rocks

Yes, that was corrected after I posted before I got anything to work.

current wiring is:

ContextResource contextResource = new ContextResource();

contextResource.setName("jdbc/sgsdb");
contextResource.setType("javax.sql.DataSource");
contextResource.setProperty("url", "jdbc:postgresql://localhost:5432/version4007");
contextResource.setProperty("driverClassName", "org.postgresql.Driver");
contextResource.setProperty("username", "postgres");
contextResource.setProperty("password", "notnull");
contextResource.setProperty("testWhileIdle", "false");
contextResource.setProperty("testOnBorrow", "true");
contextResource.setProperty("validationQuery", "SELECT 1");
contextResource.setProperty("testOnReturn", "false");
contextResource.setProperty("validationInterval", "30000");
contextResource.setProperty("timeBetweenEvictionRunsMillis", "30000");
contextResource.setProperty("maxActive", "50");
contextResource.setProperty("initialSize", "5");
contextResource.setProperty("maxWait", "10000");
contextResource.setProperty("removeAbandonedTimeout", "60");
contextResource.setProperty("minEvictableIdleTimeMillis", "30000");
contextResource.setProperty("minIdle", "3");
contextResource.setProperty("logAbandoned", "true");
contextResource.setProperty("removeAbandoned", "true");

contextResource.setProperty("factory", "org.apache.tomcat.jdbc.pool.DataSourceFactory");
ctx.getNamingResources().addResource(contextResource);

where ctx is the webapp context.

Thanks for reading!