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.
