atom feed23 messages in org.codehaus.btm.dev[btm-dev] [jira] Reopened: (BTM-35) S...
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] Reopened: (BTM-35) Support per connection transaction affinity
From:Ludovic Orban (JIRA) (ji@codehaus.org)
Date:Jan 6, 2010 3:04:37 am
List:org.codehaus.btm.dev

[
http://jira.codehaus.org/browse/BTM-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ludovic Orban reopened BTM-35:

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

Brett,

I'm not happy with that change. Handling 'most real-world use-cases' isn't good
enough, we must handle as many cases as possible.

If we don't, troubleshooting such issue will be a nightmare and will cause lots
of frustration to both users and maintainers of BTM.

In short: you 'Bad' example should work as well as the one proposed in the
original description.

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

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