[
https://issues.apache.org/jira/browse/OPENJPA-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526297
]
Patrick Linskey commented on OPENJPA-359:
-----------------------------------------
One approach might be to just create an implementation that uses
System.nanoTime(). This would only work in 1.5 environments, but that might be
good enough.
An easy way to do this would be to make a new abstract superclass of
TimestampVersionStrategy, and two implementations for providing a timestamp:
one that uses the nano calls, and one that uses the milli calls. For extra
credit, you could even make the Configuration framework choose which to use by
default based on the value of JavaVersions.VERSION.
> OptimisticLockException NOT thrown for entity using Timestamp Version when
> update from concurrent persistence contexts
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-359
> URL: https://issues.apache.org/jira/browse/OPENJPA-359
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 1.0.0
> Environment: WIntel 32
> Reporter: Albert Lee
> Priority: Minor
> Attachments: OPENJPA-359.patch
>
>
> We ran a test using Timestamp as the version field in an entity, the
> following (pseudo) test failed when an OptimisticLockException is expected:
> em1.persist( e0(pk1) );
> e1 = em1.find(pk1);
> e2 = em2.find(pk1);
> e1.setAttr( "new1");
> e2.setAttr( "new2");
> em1.merge( e1 );
> em2.merge( e2 ); <<<< Expect an OptimisticLockException
> The cause of this problem is because the TimestampVersionStrategy.nextVersion
> returns a java.sql.Timestamp(System.currentTimeMillis()); In the Wintel
> environment, the currentTimeMillis() only has approximately 15ms resolution.
> When 2 subsequent Timestamp version objects are requested within this 15ms
> interval, both has the same version value. Therefore the em2.merge does not
> detected the versions difference between o1 and o2, hence no exception is
> thrown.
> Due to this behavior, the same test case may failed intermittenly depends on
> the currentTimeMillis() resolution and the time when a timestamp version is
> created. From some preliminary tests, the resolution for wintel, linux and
> z/os are about 15ms, 2ms and 2ms respectively.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
