Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 1957 invoked from network); 26 Sep 2006 18:17:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Sep 2006 18:17:17 -0000 Received: (qmail 95607 invoked by uid 500); 26 Sep 2006 18:17:16 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 95580 invoked by uid 500); 26 Sep 2006 18:17:16 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 95571 invoked by uid 99); 26 Sep 2006 18:17:16 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Sep 2006 11:17:16 -0700 Authentication-Results: idunn.apache.osuosl.org header.from=msatoor@gmail.com; domainkeys=good Authentication-Results: idunn.apache.osuosl.org smtp.mail=msatoor@gmail.com; spf=pass X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates 66.249.82.233 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from [66.249.82.233] ([66.249.82.233:33204] helo=wx-out-0506.google.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id B9/31-14537-AAE69154 for ; Tue, 26 Sep 2006 11:17:15 -0700 Received: by wx-out-0506.google.com with SMTP id i27so2313060wxd for ; Tue, 26 Sep 2006 11:17:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=d+pu8Ec4y4ibgAFUrigNQ4rQ+jNx8Dm8CT7LUORAeDHx+jvTlQNwcFOO2Q2zKSMveLO6ufY9XTc6DmzwCeNs99J3T+4lqJ/fnE0F5IdwPtG+WBT8JWaszUE0eyMIYPHrOZxLuDiLu7+NMqheKcCsJC/iYj98/WzctRiXCLw3vU0= Received: by 10.70.87.11 with SMTP id k11mr1203507wxb; Tue, 26 Sep 2006 11:17:12 -0700 (PDT) Received: by 10.70.47.8 with HTTP; Tue, 26 Sep 2006 11:17:11 -0700 (PDT) Message-ID: Date: Tue, 26 Sep 2006 11:17:11 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: q re XA transactions and test checkDataSource In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12472_10616569.1159294631849" References: <58ed70f50609250943o4d8c294dldf5d657e89d5a6b@mail.gmail.com> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_12472_10616569.1159294631849 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 wrote: > > On 9/25/06, Deepa Remesh wrote: > > On 9/25/06, Myrna van Lunteren 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 > ------=_Part_12472_10616569.1159294631849 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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.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

------=_Part_12472_10616569.1159294631849--