[ 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