db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: question: is it possible to use a single connection for multiple threads when auto-commit is on?
Date Mon, 13 Sep 2010 11:08:41 GMT
Patrick Holthuizen <patrick@eaze.org> writes:

> Hello,
>
> In the Derby documentation I find that there are some restrictions when
> using a single connection with multiple threads. For example and especially:
>
> Here is a review of the potential pitfalls of sharing a single
> /Connection/ among multiple threads.
>
>     * Committing or rolling back a transaction closes all open
>       /ResultSet/ objects and currently executing /Statements/, unless
>       you are using held cursors.
>
>       If one thread commits, it closes the /Statements/ and /ResultSets/
>       of all other threads using the same connection.
>
>
> Now wonder if this is also true with auto-commit on? For example:
>
>
> THREAD 1                                        THREAD 2
> PreparedStatement s1 =
>     c.prepareStatement("SELECT * FROM T1");
> ResultSet rs1 = s1.executeQuery();
> rs.next();
> ...use record
>
>                                                 PreparedStatement s2 =
>                                                    
> c.prepareStatement("UPDATE T1
>                                                         SET F1 = "value"
>                                                         WHERE F2 =
> "anotherValue");
>
> rs.next();
> ...use record
>
> Do I run into troubles when the second rs.next() is called?

No, I think this should work. Note that the quote from the manual said
that the ResultSet would be closed on commit "unless you are using held
cursors."  Since Derby uses held cursors by default, the auto-commit
caused by the update statement in the above code will not close the
ResultSet.

If thread 1 first had called

    c.setHoldability(ResultSet.CLOSE_CURSORS_AT_COMMIT);

non-held cursors would have been used, and the second call to rs.next()
would have failed.

-- 
Knut Anders

Mime
View raw message