Hello,
due to some performance problems we decided to work with pinned connections.
Thus, we activated the "associatied with thread" option.
And now, under a moderate load, we can observe the following exceptions:
Caused by: java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
com.sun.enterprise.resource.pool.AssocWithThreadResourcePool.getUnenlistedResource(AssocWithThreadResourcePool.java:221)
at
com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:526)
at
com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
at
com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:259)
at
com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:178)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:341)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:304)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:190)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
at
com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:110)
at myapp.J2EECO.connectInternal(J2EECO.java:53)
We also observed some inconsistencies on the database side. We analysed our
code and the only explanation for now is that a connection can be assigned to
two threads at the same time. And it smells like a really, really serious
bug - any commit or rollback will lead then to some ugly data
inconsistencies.
Anyone saw already similar issues?
Unfortunately we cannot provide a standalone reproducer, but we can easliy
test and evaluate any patches/workarounds in our test environments.
GF 3.1 build 43, 1.6.0_24 64bit, Multi-Core Linux Maschines
We have much more working threads (twice as much) than connections in the
connection pool (it could be a problem, as the connections have to be
"reassigned" from one thread to another, but still, it should work and the
connections must not be shared across threads/transactions). There are two
active thread-pools (http and iiop).
The connection pool is configured as follows:
- dataSource impl: oracle.jdbc.pool.OracleDataSource (pretty new oracle
thin driver, 11.x)
- non transactional connections: disabled
- transaction isolation: read committed
- isolation level: guaranteed
- wrap jdbc objectes: disabled
- pooling: enabled
- associated with thread: enabled
thanks in advance for any hints,
makiey
--
[Message sent by forum member 'makiey']
View Post: http://forums.java.net/node/836231