You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Myrna van Lunteren <m....@gmail.com> on 2006/09/25 16:02:40 UTC
q re XA transactions and test checkDataSource
Hi,
In connection to trying to do remote server / IPV6 testing for the
release candidate, I ran into some behavior in the test
checkDataSource that I'm trying to understand.
I don't think there's a bug, but I do need some help.
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.
The problem I'm having is trying to drop the table ru at the end of
the test. There's a lock on it.
The lock gets set after this line in the test:
-------------------------------
showStatementState("CS GLOBAL ", csruState);
resultSetQuery("Params-global-1", psParams.executeQuery());
--> xar.end(xid, XAResource.TMSUCCESS);
My question is: how can I release the locks?
I've tried closing all statements and committing/rolling back all
connections I can see, but still the lock remains, or whatever I'm
attempting gives an error. I probably need to reattach a resource to a
connection?
Something like:
xar.start(xid, XAResource.TMNOFLAGS);
?
But what I tried so far didn't work (I've tried so many probably
non-sensible things at this point to even mention them).
How do I do this?
Thx,
Myrna
Re: q re XA transactions and test checkDataSource
Posted by Myrna van Lunteren <m....@gmail.com>.
On 9/26/06, Mamta Satoor <ms...@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
>
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
Re: q re XA transactions and test checkDataSource
Posted by Mamta Satoor <ms...@gmail.com>.
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 <m....@gmail.com> wrote:
>
> On 9/25/06, Deepa Remesh <dr...@gmail.com> wrote:
> > On 9/25/06, Myrna van Lunteren <m....@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
>
Re: q re XA transactions and test checkDataSource
Posted by Myrna van Lunteren <m....@gmail.com>.
On 9/25/06, Deepa Remesh <dr...@gmail.com> wrote:
> On 9/25/06, Myrna van Lunteren <m....@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
Re: q re XA transactions and test checkDataSource
Posted by Deepa Remesh <dr...@gmail.com>.
On 9/25/06, Myrna van Lunteren <m....@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.
Thanks,
Deepa
Re: q re XA transactions and test checkDataSource
Posted by Myrna van Lunteren <m....@gmail.com>.
Hi,
Just to be clear, my previous message wasn't accurate.
The lock is set when selects are done from the table ru.
However, once the xar.end() has been issued, with subsequent commit on
cs1, I can't find a way to release those locks so I can drop the
table.
Myrna
On 9/25/06, Myrna van Lunteren <m....@gmail.com> wrote:
> Hi,
>
> In connection to trying to do remote server / IPV6 testing for the
> release candidate, I ran into some behavior in the test
> checkDataSource that I'm trying to understand.
> I don't think there's a bug, but I do need some help.
>
> 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.
>
> The problem I'm having is trying to drop the table ru at the end of
> the test. There's a lock on it.
> The lock gets set after this line in the test:
> -------------------------------
> showStatementState("CS GLOBAL ", csruState);
> resultSetQuery("Params-global-1", psParams.executeQuery());
> --> xar.end(xid, XAResource.TMSUCCESS);
>
> My question is: how can I release the locks?
> I've tried closing all statements and committing/rolling back all
> connections I can see, but still the lock remains, or whatever I'm
> attempting gives an error. I probably need to reattach a resource to a
> connection?
> Something like:
> xar.start(xid, XAResource.TMNOFLAGS);
> ?
> But what I tried so far didn't work (I've tried so many probably
> non-sensible things at this point to even mention them).
> How do I do this?
>
> Thx,
> Myrna
>