[Jboss-dev-forums] [Design of JCA on JBoss] - Re: JBAS-1836 - contentious transaction enlistment and pooli

[<ad...@jb...>]

I've also changed the track-connection-by-tx handling in the contentious case
to avoid overly long locking of the transaction local.

Instead I trap two threads allocating different connections when the connection
should be sticky to the transaction. The second thread returns the unwanted
connection to the pool and uses the connection obtained by the first thread.

i.e.
Thread1: getConnection - no current transaction sticky connection
Thread1: get a connection from the pool, but context switch
Thread2: getConnection - no current transaction sticky connection
Thread2: get a connection from the pool
Thread2: register sticky connection and return it
Thread1: recheck for sticky connection
Thread1: there is one now, so return the connection we just got
Thread1: return the transaction sticky connection

In the non-contentious case, this requires an extra lock on the tx local
(which should be minimal overhead since there is no contention)
and an extra check of the tx local value.

Comment from the code (BasePool.getConnection):

  |          // Need a new connection for this transaction
  |          // This must be done outside the tx local lock, otherwise
  |          // the tx timeout won't work and get connection can do a lot of other work
  |          // with many opportunities for deadlocks.
  |          // Instead we do a double check after we got the transaction to see
  |          // whether another thread beat us to the punch.
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3882626#3882626

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3882626