db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Synchronization on the connection in JDBC calls
Date Fri, 30 Jun 2006 14:25:52 GMT
Daniel John Debrunner wrote:
> Kristian Waagan wrote:
> 
>> Hello,
>>
>> When working on EmbedPreparedStatement.java, I noticed that a few
>> methods synchronize on the connection object, for instance addBatch. The
>> code typically looks like this:
>>
>> synchronized (getConnectionSynchronization()) {
>>     // Do stuff
>> }
>>
>> The getConnectionSynchronization-method returns a reference to the root
>> connection. I also saw that EmbedResultSet uses this more.
>> The rest of the JDBC methods in EmbedPreparedStatement don't synchronize
>> on this object.
>>
>> I think a single connection is not expected to be shared between
>> multiple threads simultaneously. Maybe the necessary synchronization is
>> done at a lower level in the system.
>>
>> Would anyone care to share their thoughts/knowledge on this issue?
> 
> In addition to what Bryan's correct reply, I'd add that the Derby
> embedded engine requires this high level synchronization. The internals
> depend on the fact that only a single thread can be active in a context
> manager/language connection context at any time. A thread becomes active
> in a context manager/language connection context when it enters the JDBC
> api and inactive when it leaves the JDBC thread. This is shown in slides
> 18,19,20 & 33,34 of
> http://db.apache.org/derby/binaries/ApacheDerbyInternals_1_1.pdf

Thanks to both of you for your replies.
You have made it perfectly clear that we need some degree of 
synchronization at the JDBC API level.

> 
> There are some unsynchronized calls through the JDBC layer,where one can
> demonstrate that:
>    - no unxpected exceptions (E.g. NPE, IndexOfOutBounds) will be thrown
> due to potential concurrent access of any JDBC objects owned by the same
> connection.
>    - no incorrect behaviour will occur (e.g. wrong results) due to
> potential concurrent access of objects owned by the same connection.

Maybe I don't see what you mean with calls "through the JDBC layer", but 
to me it seems most, as opposed to some, JDBC calls in *Statement are 
unsynchronized.
As far as I can see, the most critical ones are synchronized, like 
'execute' and 'close' (which was used as examples in the referenced PDF).

I observe that the method 'getParameterJDBCType' in PreparedStatement 
for 'setBlob' is synchronized (and nothing else in the method), but I 
don't really see why. This code has been around for a while, but I 
intend to remove it unless someone objects or I find/understand the 
reason why it's there. I will search for code violating the two reasons 
for not synchronizing mentioned by Dan.

Also, what about CallableStatement? You can create a procedure with an 
INOUT parameter. What result you get for the getXXX call depends on when 
it is executed, ie. before/during or after the procedure execution.
Is it entirely up to the application programmer to ensure the intended 
result is fetched?
The driver could for instance help solve this by "blocking" the getXXX 
call while the procedure is being executed, *if* this is the right thing 
to do.



-- 
Kristian

> 
> Dan.
> 
> 
> Dan.
> 


Mime
View raw message