#6 JPOX persistence-by-reachability at commit fails

[Wyrm Tools]

The JPOX JDO implementation, by default, runs its
persistence-by-reachability algorithm at commit
time. In order to workaround a problem in BUG
1472714, this feature was turned off. This bug
report is being written up in the hope that in the
future someone may actually figure out what the root
cause of the problem is. In summary, the JPOX
persistence-by-reachability algorithm, when run at
commit time, will mistakenly think a newly persisted
instance is no longer reachable. See the detailed
comments below.

ENVIRONMENT:
Windows XP SP2
JPOX 1.1.0 RC1
MySQL 4.1

REPRO STEPS:
1) Create a new d20 race element (do whatever is
necessary to get the application in an appropriate
state to do this).
2) Open the race in the race editor.
3) Go to the Abilities page.
4) Set the Strength ability adjustment to "+3".
5) Save the race.
6) Set the Strength ability adjustment to "-3" (or
anything other than "0").
7) Save the race.

EXPECTED BEHAVIOR:
The race should be saved with no errors.

ACTUAL BEHAVIOR:
An exception is thrown indicating a constraint
violation.

The constraint violation is due to JPOX attempting to
delete the new PersistentScript because its
persistence-by-reachability algorithm thinks the new
object is no longer reachable even though it has
already been persisted. See the logs attached to BUG
1472714 for additional information.

I hate to bring up the term "race condition".
However, after stepping through the JPOX code with
the debugger, I could not get this problem to occur.
If I stepped over the transaction commit() statement
in the element editor, it would happen. This is
weird because I don't think there are any other
threads accessing JPOX to cause a race condition in
the first place.