db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: I need some advice to choose database for an upcomming job
Date Tue, 08 Nov 2005 12:23:35 GMT
Oyvind.Bakksjo@Sun.COM wrote:

> Daniel John Debrunner wrote:

>> In addition I guess you showRow() does a next() and then
>> the rs.gerXXX()? I think if you called t2.executeQuery() between a
>> next() and the rs.getXXX() calls on the other thread, I think you will
>> see problems.
> I tried that, but that did not change any behaviour. Besides, why would
> it? It doesn't seem logical to me why you would get an exception exactly
> there, if the resultset isn't closed and you don't get an exception on
> the subsequent next() and rs.getXXX() calls after the second execute.

My thinking is that the executeQuery() will cause a commit which will
cause the open held ResultSet used by the other thread to move off the
row, as required by the SQL standard. Thus before any getXXX() call can
be made, the held cursor needs to be re-positioned using next(). I think
you have said before that Derby doesn't act this way, though looking at
the embedded code it should.

>> Thus sharing connections across threads is just problematic unless the
>> application performs synchronization and/or has very good knowledge of
>> what others threads are doing at all times. Any application will just be
>> less error prone if it uses separate connections for separate threads,
>> isn't one of the reasons to use a relational database to not have to
>> worry about data synchronization issues? This of course is not specific
>> to Derby, the JDBC spec specifies this behavviour.
> I agree. Just to be clear, I am not arguing that anyone should code
> applications that way, I'm just trying to figure out exactly how Derby
> behaves.

Always good :-)
> Although sharing connections between unrelated threads which perform
> different tasks is not a good idea, I can imagine there are cases where
> one would benefit from having multiple open resultsets on a connection
> with autocommit off. This should be allowed, right? Also, Derby should
> be agnostic to whether these result sets are processed in different
> threads.

Yes, it's allowed, and Derby does not care what thread is processing a
ResultSet. It's just the JDBC spec mandates behaviour which means
applications which have multiple threads using a single connection need
to be co-ordinated in some way. If there is no co-ordination then any
commit or rollback by one thread can/will affect the open objects used
by the other thread(s).


View raw message