Lance J. Andersen wrote: >>>Note that executing a statement on *another* statement object in the >>>same connection no longer closes a result set, >>> > > This has never been the intent in JDBC since its inception,
Well, it sure had a funny way of showing it was not the intent :-) JDBC 1 "New JDBC connections are initially in “auto-commit” mode. This means that each statement is executed as a separate transaction at the database. In order to execute several statements within a single transaction, you must first disable auto-commit by calling Connection.setAutoCommit(false)." JDBC 3 "For Select statements, the statement is complete when the associated result set is closed. The result set is closed as soon as one of the following occurs: [...] - another Statement object is executed on the same connection" Pretty explicit in both cases, only a single statement can be active in auto-commit mode. JDBC 4.0 is proposing a change that multiple statements, possibly including updates, can be active when in auto-commit mode. I wonder if that was really the intent of EG for these changes? > From the 1.0.2 spec: > Multi-threading > We require that all operations on all the java.sql objects be > multi-thread safe and able to cope > correctly with having several threads simultaneously calling the same > object. > Some drivers may allow more concurrent execution than others. Developers > can assume fully > concurrent execution; if the driver requires some form of > synchronization, it will provide it. > The only difference visible to the developer will be that applications > will run with reduced concurrency. > For example, two Statements on the same Connection can be executed > concurrently and their > ResultSets can be processed concurrently (from the perspective of the > developer). Some drivers > will provide this full concurrency. Others may execute one statement and > wait until it completes > before sending the next. Derby/Cloudscape has always been completely compliant with the above multi-threading section. This section is also not in conflict with the current defined JDBC 3 auto commit behaviour. Dan.
