[
https://issues.apache.org/jira/browse/OPENJPA-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526171
]
Albert Lee commented on OPENJPA-359:
------------------------------------
> I don't understand. IMO, versioning in a clustered environment is a trivial
> problem
when using the monotonically-incrementing number approach. The only "problems"
arise when using timestamps, and arguably, these aren't problems, but rather
just
limitations imposed by the timing needs of the application.
>
> FTR, with a monotonically-incrementing version number, the database itself
> acts
as the central server.
If the version is handed off from the db server, then I agree with you that is
is a trivial problem. However in our implementation the version is handed off
from an instance of the persistence provider of app server (in a cluster). E.g.
NumberVersionStrategy.nextVersion() { .... return Numbers.valueOf(((Number)
version).intValue() + 1); }
TimestampVersionStrategy.netxtVersion() { return
TimestampHelper.getCurrentTimestamp(); }
TImestamp is always problematic, regardless of how accurate the value is used.
It also depends on how precise (how many fractional digits) the column in the
db are being stored. I ran into a scenario where the Timestamp version is
precise to the 100ns but the test still failed. It is because the version
column in the db only holds up to ms.
> By my definitions, sleeping for 2ms does incur a performance cost, but does
> not
incur any concurrency problem at all. In fact, doing so avoids the concurrency
problem introduced by the new synchronized block.
Sleeping in a thread to avoid duplicate time stamp only solve its own problem.
What about if there are 2 threads coming in at the same time (within the 15ms
time window) and asking for a new version. Without the synchronized block to
hand out the next value, the time stamp version created in both threads will be
same if sleep is used, which does not solve the initial problem. Even with the
current suggested solution, it does not guarantee to solve the cluster scenario.
> 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.
