[jboss-dev-forums] [Design of JBoss Transaction Services] - Re: JBAS-5801 - Locking in 2PC

[adrian@jboss.org]

"jhalliday" wrote : yes, blocking end() should eliminate the race, at the cost of the rollback no longer actually 'killing' a long running operation.
  | 

Ok that's what I'm doing. Maybe I should change the try-lock to have
a default value. Blocking forever is never a good idea.

anonymous wrote : 
  | My concern with actually interrupting the business logic operation is related to the way connections are multiplexed. You may have one or more logical connections on a single TCP/IP connection. Killing the network level one may therefore kill unrelated business operations in other threads. Depending how the multiplexing is implemented by the driver, interrupting a logical connection handle may mess up the multiplexing, with much the same undesirable side effects. Potentially you have to throw away the entire connection pool, not just a single logical connection if you want to be safe. 
  | 

No , I'm talking about doing ManagedConnection.destroy()
effectively invoke close() on all the physical connections
that are part of the timed out transaction and where the connection-factory
has been configured for this behaviour due to known or suspected
broken/hanging drivers.

Whether the underlying driver actually honours the request or is
mulitplexing underneath is another question.
It's just further option to try to recover from broken/blocking
connections causing timeouts.

Whether you also interrupt() the thread is a different issue,
since in most cases a close() - MSSQL aside - should be allowed to proceed
even with other concurrent requests.

anonymous wrote : 
  | Add to that the fact that the XA control messages probably flow over the same TCP/IP connection and you wind up with a problem. Sure, presumed rollback means that the resource manager should abort the tx when the TCP/IP connection drops, but some (db2?) don't.  You need to keep the connection intact if you want to be sure it gets terminated cleanly, or rely on the crash recovery to tidy it up.

Yes, Oracle is the same for local transactions. If you crash the connection it rolls back
when auto-commit=false. If you explicitly close it without committing, 
it commits anyway - so much for auto-commit=false :-(
So you have to do a rollback() before closing(), just to be sure.

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

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