danbim
commented
11 years ago According to this thread on StackOverflow we should never @Inject EntityManager directly but use @Inject Provider<EntityManager> instead. I'll try this...
Closed danbim closed 11 years ago
danbim
commented
11 years ago According to this thread on StackOverflow we should never @Inject EntityManager directly but use @Inject Provider<EntityManager> instead. I'll try this...
danbim
commented
11 years ago I carefully debugged and traced the behavior of the guice-persist module, if transactions are started and stopped properly, if EntityManager and UnitOfWork instances are properly opened and closed and everything seems to be working just as it should.
However, until now we always used the default database connection pool of Hibernate. At startup Hibernate prints out a warning that this connection pool is not meant to be used in production. Therefore I'm now trying to configure c3p0 connection pooling for the several persistence units, hoping that this connection pooling mechanism will not lead to stale MySQL connnections which seem to cause the errors. In order to use c3p0 pooling add the following lines to the individual JPA properties files:
# configure connection pooling for production servers
hibernate.connection.provider_class=org.hibernate.connection.C3P0ConnectionProvider
hibernate.c3p0.acquire_increment=1
hibernate.c3p0.idle_test_period=60
hibernate.c3p0.min_size=1
hibernate.c3p0.max_size=10
hibernate.c3p0.max_statements=50
hibernate.c3p0.timeout=10
hibernate.c3p0.acquireRetryAttempts=1
hibernate.c3p0.acquireRetryDelay=250and tweak the parameters as required. I traced the connection behavior using the MySQLWorkbench tool on my development machine and it seems that everything is working really fine. Also, when I run a load test using siege (e.g., doing 1000 DeviceDB requests with 10 parallel threads) seem to work exactly as configured for c3p0. As soon as the load test is over c3p0 will shut down connections to the DB, keeping only 1 running. The 1 connection that is always also seems to be kept alive as the admin interface shows a maximum "Time" of 10 seconds before it jumps back to 0 so I assume that this connection either is using some keepalive mechanism or is shut down and rebuilt immediately.
danbim
commented
11 years ago Seems this worked :)
master-lincoln
commented
11 years ago C3PO to the rescue!
and
These errors were observed on the staging testbed installation at UZL testbed after longer time of inactivity.