|
I have not run tests on this diff yet, just posting to get some input on whether I am on the right track or not. Do not commit this patch until I have had a chance to get it reviewed and run tests.
submitted to trunk as revision 351543.
Sometimes (timing dependent) a lock deadlock was incorrectly returned to the user as a lock timeout. The code in LockSet was using the wrong variable to determine if a deadlock had been detected, that variable sometimes was right and sometimes wrong. Changed all the code to use the direct return from the deadlock detection routine. Added a test that causes 5 deadlocks, previous to the fix this test would always report at least 1 timeout on my single processor, windows xp, laptop. svn 353812 ports fix from trunk to 10.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
lock deadlocks sometimes reported as lock timeouts
On my ~2 ghz single processor laptop, running windows and jdk1.4.2 when I run the test the
first time I get a deadlock, and then mostly get timeouts reported for subsequent runs.
Note that the first time there are 0 rows in the table, but after each iteration there are some
committed deleted rows which changes the internal timing - to the user since the test never
commits there are always no rows in the tables.
It is
clear that the time to the timeout is the deadlock time - NOT the timeout time.