Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <33351401.202361295995183182.JavaMail.jira@thor>
Date: Tue, 25 Jan 2011 17:39:43 -0500 (EST)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Issue Comment Edited: (DERBY-4982) Retrying after interrupts
 in store pops a bug in derbyall/storeall/storeunit/T_RawStoreFactory in
 some cases
In-Reply-To: <7271773.120951295661883722.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986221#action_12986221 ] 

Dag H. Wanvik edited comment on DERBY-4982 at 1/25/11 5:37 PM:
---------------------------------------------------------------

Uploading a patch which makes store throw a session level exception (the cleanup will possibly release the latch if held by this transaction, not sure) for both sane and insane, instead of assert for sane, and in stead of waiting eternally fo insane,  In stead of 08000, I made a new error, DATA_DOUBLE_LATCH_INTERNAL_ERROR for this situation.I chose not to make it database level since the the thread is only dead-locked with itself and we have no sign that the database is compromised. Maybe it is overkill to make a new error for this internal error which is not expected to happen, but according to Knut, waiting for lock timeout is no longer an option: we get an eternal hang. Opinions are welcome as always.

The test code has been adjusted accordingly.

Running regressions.


      was (Author: dagw):
    Uploading a patch which makes store throw a session level exception (the cleanup will release the latch if held by this transaction and and notify an other threads) for both sane and insane, instead of assert for sane, and in stead of waiting eternally fo insane,  In stead of 08000, I made a new error, DATA_DOUBLE_LATCH_INTERNAL_ERROR for this situation.I chose not to make it database level since the the thread is only dead-locked with itself and we have no sign that the database is compromised. Maybe it is overkill to make a new error for this internal error which is not expected to happen, but according to Knut, waiting for lock timeout is no longer an option: we get an eternal hang. Opinions are welcome as always.

The test code has been adjusted accordingly.

Running regressions.

  
> Retrying after interrupts in store pops a bug in derbyall/storeall/storeunit/T_RawStoreFactory in some cases
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4982
>                 URL: https://issues.apache.org/jira/browse/DERBY-4982
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.8.0.0
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: derby-4982.diff, derby-4982.stat, derby-4982b.diff, derby-4982b.stat
>
>
> Cf Myrna's comment on DERBY-4741:
> "I think the latest check-in has caused the following tinderbox failure:
> derbyall/storeall/storeall.fail:unit/T_RawStoreFactory.unit
> see: http://dbtg.foundry.sun.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/1061516-derbyall_diff.txt:
> ********* Diff file derbyall/storeall/storeunit/T_RawStoreFactory.diff
> *** Start: T_RawStoreFactory jdk1.6.0_18 storeall:storeunit 2011-01-20 23:22:23 ***
> 2 del
> < -- Unit Test T_RawStoreFactory finished
> 2 add
> > ran out of time
> > Exit due to time bomb
> Test Failed.
> *** End: T_RawStoreFactory jdk1.6.0_18 storeall:storeunit 2011-01-21 00:22:54 ***
> "
> It failed in the nightly runs with ibm 1.6 also (and 1.4.2 and 1.5). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.