[
https://issues.apache.org/jira/browse/OPENJPA-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015743#comment-13015743
]
Patrick Linskey commented on OPENJPA-1973:
------------------------------------------
> Are there exceptions to this rule that you are attempting to alleviate?
Yes -- there are times when you just don't want a given field or set of fields
to be subject to optimistic locking. The most compelling use case I can come up
with is last-modified timestamps for aggregate roots (such as the PurchaseOrder
/ LineItem case I described above). I might want to increment the PO's last
modified timestamp when a line item changes; in this case, there's no actual
change to the PO, and, if the PO has a high degree of concurrency, I might be
ok with weaker last-modified semantics in exchange for better concurrency
behavior.
As it stands in JPA, optimistic locking is object-granular. This change allows
certain fields to be unlocked, thus allowing for more fine-grained lock
control. To emulate this in JPA today, I'd need to create a new class to hold
the last-modified timestamp of a PO, and configure it to be not subject to
locking. I'd rather not have to pollute my object model like that.
A larger (and very cool) feature is to create lock groups, essentially allowing
support for a number of optimistic lock columns servicing different parts of a
single object. However, this is a bigger effort (both in terms of
implementation and tests), and right now, I only really need lock exclusion in
my app.
Does that make more sense?
> Unlocked field support
> ----------------------
>
> Key: OPENJPA-1973
> URL: https://issues.apache.org/jira/browse/OPENJPA-1973
> Project: OpenJPA
> Issue Type: New Feature
> Components: docs, jdbc, jpa
> Reporter: Patrick Linskey
> Assignee: Patrick Linskey
> Attachments: OPENJPA-1973-with-docs.patch, OPENJPA-1973.patch
>
>
> Often, it's desirable to exclude certain fields from the optimistic locking
> computation. For example, if a PurchaseOrder's lastUpdatedDate field is
> updated every time a line item is added, it may be acceptable to simply use
> the latest value instead of requiring an optimistic lock check / collision.
> Let's add support for such fields.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
