Eclipse Community Forums: EMF » [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok?

Help

Home

Home » Modeling » EMF » [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok?

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] readerPoolCapacity/writerPoolCapacity = 0 ok? [message #1794634]

Tue, 04 September 2018 09:14

Linuxhippy Mising name

Messages: 36
Registered: July 2009

Member

Hi,

We use CDO with a JDBC store as part of a larger application, which also performs "traditional" JDBC database access.
Currently an application-wide connection pool is used and CDOs internal pooling is actually considered harmful in this scenario by our admins.

I wonder - are there any downsides / issues to expect when setting reader- and writerPoolCapacity to 0 when the DataSource is backed by a connection pool anyway?

The reason I ask is because when setting the internal pool capacities to 0, I see the following Exceptions in the application logs:

java.lang.InterruptedException: null
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302) ~[na:1.8.0_121]
at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) ~[na:1.8.0_121]
at org.eclipse.net4j.util.lifecycle.Lifecycle.lock(Lifecycle.java:306) ~[na:na]
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalDeactivate(Lifecycle.java:119) ~[na:na]
at org.eclipse.net4j.util.lifecycle.Lifecycle.deactivate(Lifecycle.java:167) ~[na:na]
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:234) ~[na:na]
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:224) ~[na:na]
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:250) ~[na:na]
at org.eclipse.emf.cdo.spi.server.StoreAccessorPool.disposeStoreAccessor(StoreAccessorPool.java:182) ~[na:na]
at org.eclipse.emf.cdo.spi.server.StoreAccessorPool.addStoreAccessor(StoreAccessorPool.java:111) ~[na:na]
at org.eclipse.emf.cdo.spi.server.Store.releaseAccessor(Store.java:429) ~[na:na]
at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.release(StoreAccessorBase.java:135) ~[na:na]
at org.eclipse.emf.cdo.server.StoreThreadLocal.release(StoreThreadLocal.java:118) ~[na:na]
at org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:332) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_121]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_121]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]

followed by the connection pool, complaining connections have leaked:
WARNUNG: Connection leak detection triggered for oracle.jdbc.driver.T4CConnection@63e6ab40, stack trace follows
java.lang.Exception: Apparent connection leak detected
at org.eclipse.net4j.internal.db.DataSourceConnectionProvider.getConnection(DataSourceConnectionProvider.java:50)
at org.eclipse.net4j.internal.db.DBDatabase.getConnection(DBDatabase.java:139)
at org.eclipse.net4j.internal.db.DBDatabase.getConnection(DBDatabase.java:1)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.doActivate(DBStoreAccessor.java:804)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:127)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:117)
at org.eclipse.emf.cdo.spi.server.Store.getReader(Store.java:367)
at org.eclipse.emf.cdo.server.internal.db.DBStore.getReader(DBStore.java:456)
at org.eclipse.emf.cdo.server.internal.db.DBStore.getReader(DBStore.java:1)
at org.eclipse.emf.cdo.server.StoreThreadLocal.getAccessor(StoreThreadLocal.java:89)
at org.eclipse.emf.cdo.internal.server.Repository.getQueryHandler(Repository.java:1243)
at org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:309)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Thank you in advance, Clemens

Just to be curious - is there any technical reason behind using separate reader/writer connection pools?

[Updated on: Tue, 04 September 2018 10:01]

Report message to a moderator

Re: [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok? [message #1796799 is a reply to message #1794634]

Fri, 19 October 2018 05:29

Eike Stepper

Messages: 6463
Registered: July 2009

Senior Member

The CDO tests seem to run successfully with pool capacities set to zero, and even with pools set to null. You'd likely not profit from CDOs statement caches without CDOs pools. The test suite seems to be ~3% slower then. Just to be curious - what harm are your admins expecting when you use CDOs internal pooling?

I don't recall the reason for separate reader/writer connection pools anymore. They're likely a historical relict.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Previous Topic:	CDO failover configuration
Next Topic:	[CDO] Do EMF Transaction ResourceSetListeners also work with CDO?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Dec 15 17:45:46 GMT 2019

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter