db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: I need some advice to choose database for an upcomming job
Date Tue, 08 Nov 2005 22:39:42 GMT


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.
>
>  
>

Mime
View raw message