Optimistic Lock Groups ?

[andyjefferson]

With optimistic transactions when we perform an UPDATE / DELETE we add a WHERE clause for the VERSION, so that if nothing is updated (due to that version no longer existing, having been updated from another thread) then we throw an OptimisticLockException. This currently applies to all fields of a class, with the proviso that if a collection is updated on an object of the class then we also update the version of the owning object (even if no other fields, that are stored in that table, are updated) and then update the collection.

Kodo, when it existed, allowed the concept of lock "groups" so that you could UPDATE / DELETE without the WHERE VERSION clause when not updating a lock group field, and if any lock group fields are updated then add the WHERE VERSION clause (but with a separate version column for the specific lock group).

An example

class Address
{
    String street;
    String city;
    String country;
    String postcode;
}

and say we define a lock group containing "street" and "city" and then update just the "country", so if this lock group is active we would just do the UPDATE without any version check. If we instead updated "street" then we would add the WHERE VERSION clause.

Should we ever want to offer something like this, to be symmetrical with fetch groups, the work required would be

1. We need an annotation @LockGroup that defines the name of the group, the fields in it, and an optional column name (for the version column to use). The principal being we would have a different version column per lock group, with one for the default "group". Similarly <lock-group> in the XML handling
2. We need a way of specifying the lock group(s) that are active in a transaction, on the PM/EM

Questions to resolve

1. Do we really need to have multiple version column(s)? Could we not just have a mode that ignores collection/map fields, since they aren't stored in the same table anyway? e.g have the option of not updating the version of the owner when just a collection field is updated.
2. How do we specify which lock group(s) are active? We do have the JDO API standard method PersistenceManager setProperty(...) so could just use that and be implementation independent still.