openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <>
Subject [jira] [Commented] (OPENJPA-1973) Unlocked field support
Date Tue, 05 Apr 2011 03:50:05 GMT


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:
>             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:

View raw message