[ http://issues.apache.org/jira/browse/DERBY-898?page=all ]
Kathey Marsden updated DERBY-898:
---------------------------------
Attachment: DERBY-898.diff
DERBY-898 setAutoCommit(false) is not working properly with connections
objtained with ClientXADataSource.
The problem in this case was that the server side connection was set to
autocommit true. Even when the client has autocommit on, the server side
connection should be autocommit false and let the client drive the commits.
- Changes server side connection for network server XA to autocommit false.
- Adds connections obtained from an XADataSource to the savepointJdbc30 test to
verify that autocommit is being set properly and also verify that DERBY-899 (a
dup of this issue) is fixed.
I will commit to 10.1 later today.
> setAutoCommit(false) is not working properly for local connection with
> ClientXADataSource
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-898
> URL: http://issues.apache.org/jira/browse/DERBY-898
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0, 10.1.1.1
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Priority: Critical
> Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.3
> Attachments: DERBY-898.diff
>
> Network Server is not honoring local
> transaction rollback using ClientXADataSource. Run the following standalone
> JDBC code.
> The output shows that after rolling back the local transaction,
> the inserted data is still present.
> final org.apache.derby.jdbc.ClientXADataSource ds =
> new org.apache.derby.jdbc.ClientXADataSource();
> ds.setServerName("localhost");
> ds.setPortNumber(1527);
>
> ds.setDatabaseName("WOMBAT");
> ds.setTraceLevel(-1);
>
> ds.setSecurityMechanism(ds.CLEAR_TEXT_PASSWORD_SECURITY);
> ds.setUser("dbuser1");
> ds.setPassword("dbpwd1");
> //ds.setLogWriter(new
> java.io.PrintWriter(System.out));
> XAConnection xaConn = ds.getXAConnection();
> Connection conn = xaConn.getConnection();
>
> conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_R
> EAD);
> conn.setAutoCommit(true);
> System.out.println("Database product: " +
> conn.getMetaData().getDatabaseProductName());
> System.out.println("Database version: " +
> conn.getMetaData().getDatabaseProductVersion());
> System.out.println("Driver name: " +
> conn.getMetaData().getDriverName());
> System.out.println("Driver version: " +
> conn.getMetaData().getDriverVersion());
> Statement stmt = conn.createStatement();
> try { stmt.execute("drop table cmtest"); }
> catch (SQLException sqlX) {} // ok, didn't exist
> stmt.execute("CREATE TABLE cmtest (id integer not null
> primary key, name varchar(60))");
> stmt.close();
> conn.setAutoCommit(false);
> PreparedStatement pstmt = conn.prepareStatement(
> "INSERT INTO cmtest (id, name) VALUES(?,?)",
> ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_READ_ONLY);
> pstmt.setInt(1, 13);
> pstmt.setString(2, "blah1");
> pstmt.executeUpdate();
> pstmt.setInt(1, 2);
> pstmt.setString(2, "blah2");
> pstmt.executeUpdate();
> conn.rollback();
> PreparedStatement pstmt2 = conn.prepareStatement(
> "SELECT * FROM cmtest WHERE id = ?",
> ResultSet.TYPE_FORWARD_ONLY,
> ResultSet.CONCUR_READ_ONLY);
> pstmt2.setInt(1, 13);
> ResultSet rset = pstmt2.executeQuery();
> if (rset.next())
> {
> System.out.println("Test fails. First insert was
> not rolled back.");
> System.out.println("The data is still present. It
> is: " + rset.getObject(1) +
> ", " + rset.getObject(2));
> }
> else
> System.out.println("Test passes. First insert was
> rolled back.");
> Here's the output,
> Database product: Apache Derby
> Database version: 10.1.2.2
> Driver name: Apache Derby Network Client JDBC Driver
> Driver version: 10.1.2.2
> Test fails. First insert was not rolled back.
> The data is still present. It is: 13, blah1
> On some brief investigation I see that the Network Server embedded connection
> is in autocomit mode so is autocommitting the transaction before the
> rollback. Network server should always have autocommit false and let the
> client drive the commit.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
