db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: I need some advice to choose database for an upcomming job
Date Tue, 08 Nov 2005 19:20:28 GMT
with test interactions like this it is important to specify whether
the result sets were marked close on commit or not.  There are a number
of different ways in jdbc to do this.

Oyvind.Bakksjo@Sun.COM wrote:

> Daniel John Debrunner wrote:
> 
>> Oyvind.Bakksjo@Sun.COM wrote:
>>
>>> Note B: If you're running with autocommit OFF, you should definately not
>>> use the same connection object in multiple simultaneous requests (either
>>> use synchronization or create multiple connections).
>>
>>
>>
>> This is true even with automcommit on. Multiple threads using the same
>> connection with ResultSets will mess with each other, as per the JDBC
>> sprc. An executeQuery by one thread will close any ResultSet any other
>> thread is processing.
> 
> 
> Could you elaborate on this?
> 
> I created a small test program which Prepares two statements in separate
> threads, but uses the same connection object. I execute statement A and
> read a few rows from the resultset in thread 1, execute statement B and
> read a few rows from it in thread 2, do a little interleaved reading,
> then read the rest of the rows from both resultsets in their respective
> threads. Got no exception, indicating that no result set was closed.
> 
> I ran this in autocommit mode in both embedded and client/server mode.
> 
> Code excerpt below, in case my explanation of the test program was unclear:
> 
>             t1.prepareStatement();
>             t2.prepareStatement();
>             t1.executeQuery();
>             t1.showRow();
>             t1.showRow();
>             t1.showRow();
>             t2.executeQuery();
>             t2.showRow();
>             t2.showRow();
>             t2.showRow();
>             t1.showRow();
>             t2.showRow();
>             t1.showAll();
>             t2.showAll();
> 
> I have seen some differing behaviour with respect to this in
> client/server and embedded mode before (that's why I made the test), but
> I couldn't reproduce any issue now.
> 

Mime
View raw message