Connection.isClosed() and the IS_CLOSED_TEST connection property  Making adjustments for multithreading

Chapter 2: Programming Information

Statement.close() with unprocessed results

The JDBC specification is somewhat vague on how a driver should behave when you call Statement.execute() and later call close() on that same Statement object without processing all of the results (update counts and ResultSets) returned by the Statement.For example, assume that there is a stored procedure on the database that does seven row inserts. An application then executes that stored procedure using a Statement.execute(). In this case, a Sybase database will return seven update counts (one for each inserted row) to the application. In normal JDBC application logic, you would process those update counts in a loop using the getMoreResults(), getResultSet() and getUpdateCount() methods. These are clearly explained on the java.sun.com website in the javadocs for the java.sql.* package.An application programmer, however, might incorrectly choose to call Statement.close() before reading through all of the returned update counts. In this case, jConnect will send a cancel to the database, which could have unexpected and unwanted side effects.In this particular example, if the application called Statement.close() before the database had completed the inserts, the database might not execute all of the inserts. It might stop, for example, after only five rows were inserted because the cancel would be processed on the database before the stored procedure completed.The missing inserts would not be reported to you in this case. Future releases of jConnect may throw a SQLException when you try to close a Statement when there are still unprocessed results, but until then, jConnect programmers are strongly advised to adhere to the following guidelines:





Copyright © 2003. Sybase Inc. All rights reserved. Making adjustments for multithreading

View this book as PDF