You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Grzegorz Borkowski (JIRA)" <ji...@apache.org> on 2009/12/29 14:10:29 UTC
[jira] Created: (OPENJPA-1451) Provide additional optimistic lock
options
Provide additional optimistic lock options
------------------------------------------
Key: OPENJPA-1451
URL: https://issues.apache.org/jira/browse/OPENJPA-1451
Project: OpenJPA
Issue Type: Improvement
Affects Versions: 2.0.0-M3
Reporter: Grzegorz Borkowski
The standard @Version -based optimistic locking in JPA is too much limited in many cases. Often you need to have optimistic lock more column(cell)-level then record-level based. It can be accomplished by using old value of the modified column(s) in WHERE clause, instead of using @Version column. Other JPA implementations already provide such extensions, it would be good if OpenJPA had it too.
E.g. in Hibernate it'd done by: @org.hibernate.annotations.Entity(optimisticLock=DIRTY)
and in EclipseLink: @org.eclipse.persistence.annotations.OptimisticLocking(type=CHANGED_COLUMNS)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-1451) Provide additional optimistic lock
options
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795089#action_12795089 ]
Patrick Linskey commented on OPENJPA-1451:
------------------------------------------
Take a look at Kodo's lock groups -- they allow the developer to partition up fields in a class into named lock groups, which are then used when computing optimistic locking (either via state comparison as you described above or via multiple lock columns). One big difference between lock groups and the behaviors you referenced are that the comparison always happens across all fields in the defined lock group(s), which is a handy bit of granularity. You can get the exact behavior you described by putting every field in its own lock group and using state comparison for version detection.
It looks like this was held back by BEA when pulling OpenJPA out of Kodo, but I'm sure the architecture will support the concepts at some level, since Kodo continues to have the feature and is built on top of OpenJPA.
> Provide additional optimistic lock options
> ------------------------------------------
>
> Key: OPENJPA-1451
> URL: https://issues.apache.org/jira/browse/OPENJPA-1451
> Project: OpenJPA
> Issue Type: Improvement
> Affects Versions: 2.0.0-M3
> Reporter: Grzegorz Borkowski
>
> The standard @Version -based optimistic locking in JPA is too much limited in many cases. Often you need to have optimistic lock more column(cell)-level then record-level based. It can be accomplished by using old value of the modified column(s) in WHERE clause, instead of using @Version column. Other JPA implementations already provide such extensions, it would be good if OpenJPA had it too.
> E.g. in Hibernate it'd done by: @org.hibernate.annotations.Entity(optimisticLock=DIRTY)
> and in EclipseLink: @org.eclipse.persistence.annotations.OptimisticLocking(type=CHANGED_COLUMNS)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.