db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@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
Date Tue, 25 Jan 2011 22:39:43 GMT

    [ 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.


Mime
View raw message