[
https://issues.apache.org/jira/browse/OPENJPA-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015599#comment-13015599
]
Kevin Sutter commented on OPENJPA-1973:
---------------------------------------
Hi Patrick,
Can you expand on your scenario just a bit? I noticed in your example that you
are also using an @Version column. If that's the case, then the individual
attributes should not be used for optimistic locking comparisons, right?
OpenJPA should only be relying on the @Version column to determine optimistic
lock exceptions. Are there exceptions to this rule that you are attempting to
alleviate? Thanks for the clarification.
And, Welcome Back! :-)
Kevin
> 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
