atom feed23 messages in org.codehaus.btm.dev[btm-dev] [jira] Commented: (BTM-35) ...
FromSent OnAttachments
Mike Youngstrom (JIRA)Nov 19, 2008 10:58 am 
Mike Youngstrom (JIRA)Nov 19, 2008 11:04 am 
Ludovic Orban (JIRA)Feb 7, 2009 2:32 pm 
James House (JIRA)Feb 12, 2009 11:54 am 
Ludovic Orban (JIRA)Feb 12, 2009 1:14 pm 
Ludovic Orban (JIRA)Mar 22, 2009 5:07 am 
Ludovic Orban (JIRA)Jan 4, 2010 10:03 am 
Brett Wooldridge (JIRA)Jan 4, 2010 10:15 pm 
Brett Wooldridge (JIRA)Jan 4, 2010 10:17 pm 
Brett Wooldridge (JIRA)Jan 5, 2010 3:13 am 
Brett Wooldridge (JIRA)Jan 5, 2010 3:15 am 
Ludovic Orban (JIRA)Jan 6, 2010 3:04 am 
Brett Wooldridge (JIRA)Jan 6, 2010 7:26 am 
Brett Wooldridge (JIRA)Jan 6, 2010 7:28 am 
Brett Wooldridge (JIRA)Jan 6, 2010 7:44 am 
Brett Wooldridge (JIRA)Jan 6, 2010 9:03 am 
Brett Wooldridge (JIRA)Jan 6, 2010 4:12 pm 
Ludovic Orban (JIRA)Jan 8, 2010 2:42 am 
Brett Wooldridge (JIRA)Jan 12, 2010 8:29 pm 
Brett Wooldridge (JIRA)Jan 12, 2010 8:39 pm 
Ludovic Orban (JIRA)Jan 14, 2010 7:15 am 
Brett Wooldridge (JIRA)Jan 14, 2010 7:38 am 
Brett Wooldridge (JIRA)Jan 14, 2010 7:40 am 
Subject:[btm-dev] [jira] Commented: (BTM-35) Support per connection transaction affinity
From:Brett Wooldridge (JIRA) (ji@codehaus.org)
Date:Jan 6, 2010 9:03:37 am
List:org.codehaus.btm.dev

[
http://jira.codehaus.org/browse/BTM-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205408#action_205408
]

Brett Wooldridge commented on BTM-35:

Heh, talking to myself ... answering my own questions. I was able to create a
testcase in which I create a transaction, suspend() it, pass it to two threads,
which both resume() it and then obtain connections and create statements. So, I
assume it is possible for a transaction to be running on multiple threads. As a
result, I've updated the code (checked-in) to account for thread association.
So, while a connection within a transaction will be shared, it will only be
shared to callers on the same thread. This will avoid any issues with two
threads interacting with the same cached PreparedStatement.

Support per connection transaction affinity

-------------------------------------------

Key: BTM-35 URL: http://jira.codehaus.org/browse/BTM-35 Project: BTM Issue Type: Improvement Affects Versions: 1.3.2 Reporter: Mike Youngstrom Assignee: Brett Wooldridge Fix For: 1.3.4

Attachments: patch.txt

Situations such as the below test case currently don't work with BTM: UserTransaction utx = TransactionManagerServices.getTransactionManager(); utx.begin();

DataSource ds = ... ; // Get an istance of
bitronix.tm.resource.jdbc.PoolingDataSource here

Connection connection = ds.getConnection(); Connection connection2 = ds.getConnection();

PreparedStatement stmt1 = null, stmt2 = null; ResultSet rs = null; try { stmt1 = connection.prepareStatement("INSERT INTO TEST_TABLE (ID, DESCR)
VALUES (?, ?)"); stmt1.setInt(1, 1); stmt1.setString(2, "test"); stmt1.execute();

stmt2 = connection2.prepareStatement("SELECT * FROM TEST_TABLE WHERE
ID=?"); stmt2.setInt(1, 1); rs = stmt2.executeQuery(); while (rs.next()) { System.out.println(rs.getInt(1) + " -- " + rs.getString(2)); } } catch (Exception e) { System.out.println(e); } finally { rs.close(); stmt1.close(); stmt2.close(); connection.close(); connection2.close(); }

utx.commit(); This may not be a problem when using XA transactions from some vendors but is a
problem with postgresql and in the nonXA use cases. If BTM's pool could track
connections requested from the pool and return the same connection for every
ds.getConnection() in the same transaction then situations such as this would
work in the PostgreSQL and the nonXA cases. There may be more work involved such as close suppression of various JDBC
interfaces if that is not done already so that the connection is not returned to
the pool until the transaction is committed. Mike