Jagdish,
May be I am not being clear. Connection sharing is absolutely essential in Local Transaction case (I don't know how else can one manage local txn if there are more than one resources without resorting to XA and simulating something similar to XA)! and this is the point I have been trying to make all along. Why does Glassfish need to get a new ResourceHandle in nested getConnection() calls, especially when the getConnection() is on the same resource and then associated the connection much later (to the connection is J2EETransaction nonXaResource) realizing that needs to share connection (again in the case of Local Txn) ?
Just to recap:
1. We are involved in a local transaction (no XA/2PC, not XA data sources are used, no XA/2PC optmization to 1 phase due to only one resource particiapting in the txn).
2. There can (or should) ever be only one transactional resource because of there are more than one would need XA semantics to get it right.
3. In this scenario, get connection() should always return the same connection (i.e connection is always shared across all EJBs for all calls within the same local transaction). Doesn't matter how many times one calls get connection() whether sequential or nested. Glassfish gets the sequential part right. That part is NOT A PROBLEM. Its the nested connection gets which are a problem.
4. Glassfish works perfectly fine with XA transactions [having debugged the glassfish source code extensively to find root cause of this problem, I think its the fact that same code is used for local tx and xa tx is source of the problem]
It is very simple to make Glassfish run out of connections in the connection pool. Just have one ejb call another ejb method in a loop where first ejb does not close its connection before entering the loop. The 2nd EJB must not start a new transaction i.e. the 2nd ejb's method must run in calling ejb's transaction. The 2nd ejb gets connection from the same database connection pool, it does close it when it is done. The calling ejb closes the connection after the loop. If this loop happens to have iterations more than the connection pool size, Glassfish run out of connections. Even if loop is not larger than pool size, the connections are taken from pool but never used in the transaction because of the need to share connection (which is essential).
Try this test case and see if Glassfish doesn't run out of connections in the pool.
We created an adapter that wraps get connection call in a proxy and does what glassfish should be doing. And we get correct semantics.
By the way WebLogic Server gets this right [ As I mentioned I am porting an existing application from WebLogic to Glassfish and the nested get connection is all over this large application. We run out of connections in the pool in just 5 minutes in glassfish with connection pool size set to 60! It works perfectly fine on WebLogic Server. For us to be able to port this application is to patch glassfish or write an adapter/intercetor/proxy around glassfish or fix the code base or else our application will not port. Fixing the code base is out question because it a huge effort on this code base. If even we fix it, its not possible to make sure we have 100% coverage of the codebase where this pattern is being used and we don't want to finding this out in production. So our solution is to have a proxy/interceptor sitting between our app and glassfish and it works perfectly fine for us.]
[Message sent by forum member 'sanjaydwivedi' (sanjaydwivedi)]
http://forums.java.net/jive/thread.jspa?messageID=224595