Exerp from http://castor.exolab.org/locking.html :
....
Access mode: Database Locked
The locked mode performs optimistic locking using the underlying
database engine to assure that only one transaction has access to the
record. In addition to acquiring a write lock in memory, Castor performs
a query with a special SQL construct (FOR UPDATE in Oracle, HOLDLOCK in
Sybase) to guarantee access by one transaction.
....


What is described there is actually *pesimistic* concurency control, the advantage of optimistic concurency control is precisely the absence of locking :

http://swig.stanford.edu/pub/summaries/database/optimistic_concurrency.html

http://www.cogs.susx.ac.uk/users/ianw/teach/dist-sys/ds-node197.html

http://www.cogs.susx.ac.uk/users/ianw/teach/dist-sys/ds-node198.html

Now, the next question : Dos castor support an optimisic mode ?

Optimistic concurrency control would be a great addition to Castor,
and the good news is that it's trivial to implement in the context
of O2R mapping :

  i)  add a version column to each table (with 0 as the initial value)
  ii) add the following condition to all updates

      update X
        set (x1,x2,...,version)
        values (a1, a2,..., version = version + 1)
      where
        version = ?  <-- condition for all updates...

  where ? takes the value that was fetched from the DB
  at read time.

that's it that's all...


Another key advantage of optimistic cc, in the context of O2R is that it is clusterable *out of the box*, (provided that other modes are not used), of course flushing 'dirty' instances of objects in lateral VMs would be an almost necessary condition to make such a mode useable, but as opposed to shared,and exclusive modes, it does *not* require cross VM synchronization.

....

.... ok, I went to look at the sources, in :

 org.exolab.castor.jdo.engine.SQLEngine {
    public Object store( Object conn, Object[] fields, Object identity,
                         Object[] original, Object stamp )

if ( stmt.executeUpdate() <= 0 ) { <---- here ...


and an optimistic scheme is indeed implemented, so the question now becomes, is it possible to have a mode where one relies *only* on dirty checking ? i.e. no locking whatsoever ?

----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev




Reply via email to