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 "Mike Matrigali (JIRA)" <ji...@apache.org> on 2014/07/30 20:40:38 UTC
[jira] [Comment Edited] (DERBY-6669) Transactional integrity not
maintained properly in multi-threaded system
[ https://issues.apache.org/jira/browse/DERBY-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079728#comment-14079728 ]
Mike Matrigali edited comment on DERBY-6669 at 7/30/14 6:38 PM:
----------------------------------------------------------------
a pure derby test case is always the best so that a developer can repro in their environment.
One thing that might be easy for you to do is to enable derby to write out each statement
as it executes into the derby.log and provide that log. See documentation about
derby.language.logStatementText.
It may be necessary to see what isolation level the problem statement is using. To do that
we will need to see the queryplan of that statement. There are various ways to get that output.
As a first step I would suggest looking at documentation for derby.language.logQueryPlan.
If you have a reproducible case in your environment for debugging, you should be able to
set these properties, boot the database, run the test case from the beginning to end, shut
down the db and provide the db along with note on what line number has the query that is
doing the wrong thing.
Do note that setting these parameters will change execution timing. statement logging is the least intrusive with plan logging being more intrusive.
was (Author: mikem):
a pure derby test case is always the best so that a developer can repro in their environment.
One thing that might be easy for you to do is to enable derby to write out each statement
as it executes into the derby.log and provide that log. See documentation about
derby.language.logStatementText.
It may be necessary to see what isolation level the problem statement is using. To do that
we will need to see the queryplan of that statement. There are various ways to get that output.
As a first step I would suggest looking at documentation for derby.language.logQueryPlan.
If you have a reproducible case in your environment for debugging, you should be able to
set these properties, boot the database, run the test case from the beginning to end, shut
down the db and provide the db along with note on what line number has the query that is
doing the wrong thing.
> 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
>
> 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)