atom feed9 messages in org.codehaus.btm.devRe: Re: [btm-dev] Support per connect...
FromSent OnAttachments
Ludovic OrbanJan 8, 2010 2:36 am 
Brett WooldridgeJan 8, 2010 3:02 am 
jhouseJan 8, 2010 10:30 am 
Brett WooldridgeJan 8, 2010 8:18 pm 
Ludovic OrbanJan 10, 2010 10:48 am 
Brett WooldridgeJan 12, 2010 6:07 pm 
Brett WooldridgeJan 12, 2010 8:50 pm 
Ludovic OrbanJan 14, 2010 4:27 am 
Brett WooldridgeJan 14, 2010 5:19 am 
Subject:Re: Re: [btm-dev] Support per connection transaction affinity (BTM-35)
From:Brett Wooldridge (bret@gmail.com)
Date:Jan 12, 2010 6:07:40 pm
List:org.codehaus.btm.dev

Ludovic,

That's not quite correct. The original use case in BTM-35 is not outside of a transaction. The transaction is started, and then two connections are obtained. The expected result is that the two logical connections are in fact the same physical connection.

Outside of a transaction it is invalid to return the same physical connection. For example:

Connection conn1 = ds.getConnection(); Connection conn2 = ds.getConnection();

Statement stmt = conn1.createStatement("..."); stmt.executeUpdate();

Statement stmt2 = conn2.createStatement("...); stmt2.executeUpdate();

conn1.commit(); conn2.rollback();

If the two connections are the same physical connection, the commit() on conn1 will commit the changes made on conn2, and the rollback() will throw an exception.

Only within the context of a transaction is it valid to return the same physical connection from the pool.

Brett

On Mon, Jan 11, 2010 at 3:48 AM, Ludovic Orban <lor@bitronix.be> wrote:

There is a more fundamental problem to this issue in my opinion and that was one of the reasons why I rejected Brett's latest change: it's all about usability.

The example scenario originally posted by Mike Youngstrom is quite an interesting one in this regard (see first comment under http://jira.codehaus.org/browse/BTM-35as a reminder): he makes two getConnection() calls before starting the transaction then expects the returned connection to be one and unique.

I'm not sure if such case should be supported but the XA / non-XA context switch should be handled as transparently as possible as one would expect it to work and throw exceptions with meaningful error messages if something isn't possible. I'm very strict on this as usability (in the sense 'works as I think it should') is one of the top reasons behind BTM's success IMHO.

If we had to support such use case then I think the only way would be to store the acquired connection in a thread local at the XAPool level. This doesn't fit very well in the connections lifecycle's FSM but the impact could be minimal.