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
On 9/25/06, Myrna van Lunteren <[EMAIL PROTECTED]> wrote:
On 9/25/06, Deepa Remesh <[EMAIL PROTECTED]> wrote:
> On 9/25/06, Myrna van Lunteren < [EMAIL PROTECTED]> wrote:
>
> > The problem is that the test doesn't clean up after itself. Thus,
> > subsequent tests - e.g. checkDataSource30 - (which run on the same
> > database with remote server testing) fail.
> >
> > This test used to pass because of a subtest that used to get skipped
> > for DerbyNetClient.
>
> Which subtest is causing the problem with cleanup? Maybe, that will
> provide some clue as to what is going on.
>
Sorry Deepa - that bit about used to get skipped may not be true
either (sorry, I've just been too confused).
The section with which I have a problem is the section in the code
starting with
System.out.println("Issue setTransactionIsolation in local transaction");
underneath a comment:
//Derby-421 Setting isolation level with SQL was not getting
handled correctly
Myrna
