Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 30 Jul 2014 22:18:39 +0000 (UTC)
From: "Karl Wright (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12727905.1405597476718.80880.1406758719484@arcas>
In-Reply-To: <JIRA.12727905.1405597476718@arcas>
References: <JIRA.12727905.1405597476718@arcas>
Subject: [jira] [Comment Edited] (DERBY-6669) Transactional integrity not
 maintained properly in multi-threaded system
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Karl Wright edited comment on DERBY-6669 at 7/30/14 10:18 PM:
--------------------------------------------------------------

This is the annotated manifoldcf.log.  I have not correlated back to derby.log queries; hopefully the timestamps will make that straightforward.

The part of the test that fails is annotated beginning at the first >>> in the file.  The records that are messed up are JOBQUEUE table records with id's 1406755305836 and 1406755305835.  See all annotation comments beginning with ">>>" for explanation of what I believe is incorrect behavior.  Bear in mind that these records are accessed in a transaction with FOR UPDATE both explicitly (with id=xxx queries) and implicitly (with some other query criteria).  The threads involved for the 836 record are worker thread 20 (and its helper threads) as well as worker thread 15 (and its helper threads).  Please let me know if you need any clarification.  The 835 record is modified by both worker thread 20 and worker thread 17 simultaneously.


was (Author: kwright@metacarta.com):
This is the annotated manifoldcf.log.  I have not correlated back to derby.log queries; hopefully the timestamps will make that straightforward.

The part of the test that fails is annotated beginning at the first >>> in the file.  The records that are messed up are JOBQUEUE table records with id's 1406755305836 and 1406755305835.  See all annotation comments beginning with ">>>" for explanation of what I believe is incorrect behavior.  Bear in mind that these records are accessed in a transaction with FOR UPDATE both explicitly (with id=xxx queries) and implicitly (with some other query criteria).  The threads involved for the 836 record are worker thread 20 (and its helper threads) as well as worker thread 17 (and its helper threads).  Please let me know if you need any clarification.

> Transactional integrity not maintained properly in multi-threaded system
> ------------------------------------------------------------------------
>
>                 Key: DERBY-6669
>                 URL: https://issues.apache.org/jira/browse/DERBY-6669
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.10.1.1, 10.10.2.0
>         Environment: Windows; not clear if the same failure will occur on Linux or not, timing seems to be critically important.
>            Reporter: Karl Wright
>         Attachments: DERBY-6669.zip, manifoldcf.log
>
>
> The Apache ManifoldCF project uses Derby for testing and small deployments.  We're seeing a situation where transactional integrity is compromised.  Please refer to CONNECTORS-998 for complete details, as well as a test case you can run to reproduce the problem.
> I am happy to run the failing example on the same hardware I used to generate the log, if that would be helpful.


--
This message was sent by Atlassian JIRA
(v6.2#6252)