Folks,
I think I may discovered a bug in Glassfish connection pool implementation in the case of Local Transactions (i.e. no XA or 2PC distributed txn).
Scenario:
1. within a transaction in an ejb call get connection on a transaction pool (with javax.sql.DataSource not XADataSource).
2. call another get connection() on the same pool without closing the connection obtained above in 1 in the same transaction and method call [don't know why one would need to do this but lets say it is being done, I happen to be porting a legacy code from WebLogic to Glassfish and this is piece of code relies on some WebLogic connection pooling behavior].
In this scenario Glassfish correctly figures out that it is a local transaction and swaps the underlying database connection in the 2nd call with the connection obtained in step 1. But it still:
(a) obtains a new ResourceHandle with an underlying ManagedConnection which has a new database connection.
(b) enlists this new ResourceHandle in the current transaction's resource list.
Now when close is called on the connection obtained in step 2 above, glassfish will associate back the underlying database connection obtained in step 2 to ManagedConnection which is part of ResourceHandle obtained in step 2. But the interesting part is that in this case Glassfish will never use this ResourceHandle on any future get connection call in the same transaction since it is local transaction but will continue to hold on to the ResourceHandle and hence the underlying ManagedConnection until the transaction is committed.
The problem gets worse if the nested get connection is called in a loop, in that case glassfish runs out of connections in the pool.
- Glassfish will always allocated a connection from the pool because it obtains a ResourceHandle and enlist the resource in the current transaction
- These connections are never release back to the pool until transaction is committed.
The interesting part is that glassfish will always use the same physical connection obtained with the first get connection call because it is local transaction.
If this is a known problem/bug please let me know. I am planning to file an issue on this problem.
I believe Glassfish should not obtain new Resource Handle on the same resource because it will any way not use the underlying connection because of connection association logic.
--
Sanjay
[Message sent by forum member 'sanjaydwivedi' (sanjaydwivedi)]
http://forums.java.net/jive/thread.jspa?messageID=224047