On 9/26/06, Mamta Satoor <[EMAIL PROTECTED]> 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
Hi,
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...
Thx,
Myrna
