db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: q re XA transactions and test checkDataSource
Date Wed, 27 Sep 2006 12:32:01 GMT
On 9/26/06, Mamta Satoor <msatoor@gmail.com> wrote:
> Hi Myrna,
> I spent some time on this and found that the global transaction started on
> line 471 in checkDataSource.java ends up having locks on table ru when it
> does select from ru.
> Those locks are not getting released because the global transaction is never
> finished with a commit/rollback. You can release these locks by committing
> the global transaction after line 531, using xar2.commit(xid, true);
> The drop table after the global transaction commit should work fine. I had
> following after the global transaction commit and didn't get any locking
> errors for it.
>   sruState.executeUpdate("drop table ru");
> Hope this helps,
> Mamta

Mamta, that helped, thank you...

I have a follow-up problem, though...
And this is only with DerbyNetClient (not embedded).

If I do as mamta suggested - i.e. sruState.executeUpdate("drop table
ru"); I see the test PASS, however, in the
DerbyNetClient/checkDataSource/derby.log I see a failed select pop up
because the table does not exist.

So something must still be trying to select. Or one of the statements
is being deferred? It seems to only get executed when the test is
practically done.
Any suggestions on how to tell which statement that is?
(I looked at it some more but I can't see it). Or tell me how I could
find out...


View raw message