Re: I need some advice to choose database for an upcomming job

[Lance J. Andersen]

Daniel John Debrunner wrote: 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)." I assume you are refering to the JDBC 102 spec , i am aware of this verbage. The above wording does not specify what happens to the Statement that was active.  Is it commited or rolled back?  I am sure your milage varies as it does if you do a Connection.close() and there is an active transaction (The SQL standard differs from the reality of vendors.  Some commit, some rollback some just give an Error and expect the user to address it as the standard suggests) 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? The JDBC 3 spec intermixed when a ResultSet was closed with auto-commit semantics and these both are seperate scenarios.  These should have been seperated. The verbage in JDBC 3 WRT to  having another Statement executed on the same connection was not explict WRT auto commit as it was written and led to confusion. Perhaps 1 more bullet could be added to clarify this *specific* scenario as to the state of the ResultSet, i will see. 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.