[
https://issues.apache.org/jira/browse/DERBY-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3624:
--------------------------------------
Attachment: barrier.diff
The test originally did this:
Thread 1:
read all rows from table B
sleep 1/2 sec
insert a row into table A
Thread 2:
read all rows from table A
sleep 1/2 sec
insert a row into table B
The patch changed it so that each thread, after first sleeping for half a
second, would wait until the lock table contained at least two locks.
Although this reduced the chance of one thread executing the INSERT statement
before the other thread had completed the SELECT statement, it didn't
completely plug the hole. I think the problem is that it only checks that the
lock table contains two locks, and not that the two locks in fact are row locks
on table A and table B. The locks could for example be locks on system tables
held while one of the SELECT statements is compiled, in which case the other
thread would mistakenly conclude that the other thread was done executing the
SELECT statement, and it might go on and execute the INSERT statement too early
to get a deadlock.
The attached patch [^barrier.diff] changes the wait logic so that it uses the
Barrier class to make sure the other thread has executed far enough that it's
safe to go on. It no longer checks the contents of the lock table. Instead,
each thread will wait after executing the SELECT statement until the other
thread has signaled that it too has completed the SELECT statement.
I repeated Kathey's experiment with a long sleep at the beginning of t2.run(),
and the test still passes with the new approach.
> testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one
> deadlock message missing
> ---------------------------------------------------------------------------------------------------
>
> Key: DERBY-3624
> URL: https://issues.apache.org/jira/browse/DERBY-3624
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.4.1.3, 10.8.3.3, 10.10.2.0, 10.11.1.1, 10.12.0.0
> Environment: iseries, ibm 1.5.:
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
> Classic VM (build 1.5, build JDK-1.5, native threads, jitc_de)
> Reporter: Myrna van Lunteren
> Labels: derby_triage10_8
> Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.0, 10.11.1.1
>
> Attachments: barrier.diff, derby-3624_diff.txt, derby.log,
> st_derby715.tmp
>
>
> I saw this fail once; a couple of reruns didn't duplicate the problem.
> The only difference appears to be that one of the deadlock messages is
> missing from the output.
> 4 del
> < Got a Deadlock.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
