----- Original Message -----
From: "Andrus Adamchik" <andru..bjectstyle.org>
To: <cayenne-deve..bjectstyle.org>
Sent: Friday, January 23, 2004 8:03 AM
Subject: Re: Optimistic locking xml syntax
> > 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)
>
> Andrus
>
I agree. The entity "lock-type" level seems very natural in most cases and
much less error-prone from the application developer's point of view.
Let me also draw your attention to one locking (actually, its area of
applicability is wider) implementation pattern. In general, when one works
with the database over a consistent object layer, two possible solutions
become available for both the pessimistic and optimistic locking types. The
first strightforward one is to employ the locking mechanizm implemented in
the database.
Cons:
Any application accessing the same data is forced to respect the imposed
locks.
The implementation is usually mature and highly optimized.
Pros:
Sometimes it won't be portable across different databases, due to the often
obscure disctinctions in the provided locking implementations.
A database works on the level lower than that of the object layer and now
and then you have to jump through the hoops to lock object structures by way
of locking the data rows.
The second approach is to implement the locking directly in the object layer
(in fact, these two approaches often coexist to the benefit of the widest
spectrum of applications). This implies we are expected to exploit the data
(mostly) by means of this layer and the application instances residing in
the different JVMs can communicate transparently to the application
developer. Thus when a locking operation is due in one application instance
the data object layer broadcasts this event to the other instances and they
are in turn supposed to respect the established lock. Of course, the data in
the database can still be modified by an application not aware of this level
of locking. This approach is much more flexible and truly portable, also you
can implement it consistently in terms of the OO world. I believe with
introduction of the notion of interop, shared caches, and inter JVM
broadcasting facility to Cayenne 1.1 by Andrus this option becomes available
and highly attractive for exploitation. In 1.0 I emulated this behavior in
the very application specific way and even so archived some good results for
Java rich clients working with the same data over the Web. This is something
desperately needed by mature business applications.
Andriy.
This archive was generated by hypermail 2.0.0 : Fri Jan 23 2004 - 04:03:53 EST