This content has been marked as final.
Show 4 replies
-
1. Re: long-lived sessions and connection management
bill.burke Mar 31, 2005 10:47 AM (in response to bill.burke)"bill.burke@jboss.com" wrote:
There are two main problems (which I mentioned in earlier e-mails):
1) The ordering of the synchronizations, i.e. does your
connection.close() get invoked before the CCM's synchronization
to check whether the connection is closed. Otherwise they will
be invoked in the wrong order and the CCM will complain you
didn't close the connection.
So, if the synchronization that closes the connection is registered before the CCM's synchronization, we're ok?
If it is OK, I'll still get that stupid warning correct? Is there a way to turn off the CCM? I saw the Debug=true flag in the doco, but don't there doesn't seem to be a switch for it without specifying the entire MBean configuration for the connection pool.
BTW, in EJB3 I currently do not have a CCM interceptor. Will this cause a leak within the connection pool's internal house-keeping?
Thanks -
2. Re: long-lived sessions and connection management
adrian.brock Mar 31, 2005 11:22 AM (in response to bill.burke)"bill.burke@jboss.com" wrote:
So, if the synchronization that closes the connection is registered before the CCM's synchronization, we're ok?
No, because JCA registers one synchronization on first use of JCA in the transaction and accumulates other work in that (just like the entity bean global synchronization).
See TxSynchronizer.
If it is OK, I'll still get that stupid warning correct? Is there a way to turn off the CCM? I saw the Debug=true flag in the doco, but don't there doesn't seem to be a switch for it without specifying the entire MBean configuration for the connection pool.
Don't understand this. The CCM is deployed once in jbossjca-service.xml
BTW, in EJB3 I currently do not have a CCM interceptor. Will this cause a leak within the connection pool's internal house-keeping?
If there is no context established on the thread by the interceptor, the CCM
won't do the checking. You should still be able to see the unclosed connections
on the CCM (list in use operation). But without the interceptor it is unreliable
since it relies on the GC removing the closed connections from the WeakHashMap
as they are closed/dereferenced.
Unclosed connection handles will still be referenced (by the ManagedConnection)
and so won't get GCed. -
3. Re: long-lived sessions and connection management
adrian.brock Mar 31, 2005 11:31 AM (in response to bill.burke)Actually, that last statement is no longer true.
I remember fixing the connection.close to tidyup the WeakHashMap immediately:
http://cvs.sourceforge.net/viewcvs.py/jboss/jbosscx/src/main/org/jboss/resource/connectionmanager/CachedConnectionManager.java?r1=1.8.2.16&r2=1.8.2.17 -
4. Re: long-lived sessions and connection management
adrian.brock Mar 31, 2005 11:49 AM (in response to bill.burke)"adrian@jboss.org" wrote:
JCA registers one synchronization on first use of JCA in the transaction and accumulates other work in that (just like the entity bean global synchronization).
See TxSynchronizer.
And to clarify this statement, JCA needs a tx synchronization in the following
circumstances:
1) track-connection-by-tx (true for all local datasources and at least OracleXA)
to return the connection to the pool at the end of the transaction.
2) If the EJB does not close the connection during the invocation, it registers
a synchronization to check whether it was done later at transaction end.