Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.3.2
-
Fix Version/s: 2.0.0
-
Labels:None
-
Testcase included:yes
-
Number of attachments :
Description
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())
} 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
