db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: q re XA transactions and test checkDataSource
Date Tue, 26 Sep 2006 18:17:11 GMT
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,

On 9/25/06, Myrna van Lunteren <m.v.lunteren@gmail.com> wrote:
> On 9/25/06, Deepa Remesh <dremesh@gmail.com> wrote:
> > On 9/25/06, Myrna van Lunteren <m.v.lunteren@gmail.com> 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

View raw message