[
https://issues.apache.org/jira/browse/OPENJPA-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526062
]
Patrick Linskey commented on OPENJPA-359:
-----------------------------------------
> When you say clustered environment, do you mean multiple appl servers
> (in a cluster) accessing the same db server?
Yes.
> I agree with you that Versioning support in cluster environment is a hard
> problem and it is not only for Timestamp but any type. Until there is a
> central
> "server" that hands out unique version id, it will remain to be a insoluble
> problem.
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.
> sleeping for 2ms per se is an artificial performance and concurrency
> inhibitors
> which I don't recommend.
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.
> 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.
