long-lived sessions and connection management

[bill.burke]

Recent discussion between Adrian an I.

On Wed, 2005-03-30 at 22:58, Bill Burke wrote:

>> You said there are weird behaviors when a connection is kept open after
>> TX. What if the connection is closed in afterCompletion? Is there
>> gonna be a lot of overhead?


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.

2) The connections being allocated against in seemingly random EJB
contexts as the CCM sees it. i.e. opened in one and closed in another

(2) is the subject of that bug report I mentioned and started a
discussion in the linked dev forum post.


>>
>> I ask this because I'm doing some special EJB3/Hibernate integration.

[bill.burke]

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

[adrian.brock]

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.

[adrian.brock]

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

[adrian.brock]

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.