Haven't really investigated locking implementation yet, so in my response
I may overlook some aspects... anyway..
> I wonder if some points of the following might make sense:
>
> 1. Instead of "isOptimisticLock" or a similar attribute the more general
> attribute "lockType" could be introduced. It will allow to define the
> 'optimistic', 'pessimistic', or 'none' locking types in the exclusive
> mode in the future.
This is a good idea. Just a few implementation notes.
I had a little chat with an expert DB developer tonight, and it looks like
only a few databases (namely Oracle) would support locking a subset of
columns in the table in a "pessimistic" lock scenario (a.k.a SELECT ...
FOR UPDATE). Most will lock the whole table row (or even worse - the
"page" or the whole table, like older Sybase used to do). I guess all we
can do about these differences is to educate the users that even though
they mark a set of attributes as a "pessimistic" lock, RDBMS may lock much
bigger chunk of data than expected.
Also seems like it is pointless to mix optimistic and pessimistic locks in
the same entity... So "lock type" becomes a property of the entity holding
the attributes, not the attributes themselves. XML would have "lock-type"
for ObjEntity and "lock (true|false)" for the attributes (sidenote: though
the current XML style is not very consistent, most of the names are all
lowercase with dashes separating the words)
> 2. Maybe, the locking should be declared on the level of obj entities as
> opposite to db entities as it often becomes part of the domain logic
> like the transactional behavior does and in those cases data objects
> should likely be aware of it (if it is db-attribute, they won't, at
> least explicitly).
I agree - this seems right intuitively. One concern - how do we lock on
columns that are not the part of object domain? I guess we'll have to
force users to map any columns they plan to lock.
> 3. Sometimes we want to put the locking relevant flags (timestamps,
> etc.) in a separate entity and refer to it from the domain entities
> requiring locking instead of defining a timestamp per database table. In
> this case the corresponding ObjRelationship might be a good candidate to
> mark as a participant in the locking behavior.
>
> 4. Elaborating a bit more on topic 3. one often wants to lock an update
> to an entire data object subgraph based on its root, this happening when
> several tables compose a single domain concept (consider something like
> credit card info with its billing address (one table-entity) and its
> number/exp. date/owner name (second table-entity) , when both of them
> must be updated simultaniously based on a single timestamp). So it might
> be very helpful to explicitly define an entity as a source of locking
> for several related entities. I often use this pattern with the Cayenne
> data object hierarchies (of course, I had to build an application
> specific locking mechanizm, but there is room for generalization)
Makes sense to me. If we can pull this off, I am all for it.
> ----- Original Message -----
> From: "Mike Kienenberger" <mkienen..laska.net>
> To: <cayenne-deve..bjectstyle.org>
> Sent: Thursday, January 22, 2004 9:28 PM
> Subject: Optimistic locking xml syntax
>
>>
>> I have no idea if what I produce will be "good enough" to commit, but
>> I'd like to at least write it so that it's compatible with whatever
>> optimistic locking is eventually put into cayenne.
Mike, as we can see from this thread, having a discussion brings lots of
good ideas. Would be great if you share your progress on this list. This
way we may converge on a solution that we might ultimately use in Cayenne
with minumal tweaking/rewriting.
Andrus
This archive was generated by hypermail 2.0.0 : Fri Jan 23 2004 - 01:03:40 EST