Well, step 1 is actual (not just perceived) at the time of the SELECT.
We are optimistically (hence the name) expecting it to be actual at the
time of an UPDATE, too.
Step 2: Yes, Cayenne caches the original DB values. This is how Cayenne
can determine what has changed (if anything). I don't believe Hibernate
has this feature, but I could be wrong.
As for 3, there should only be SET clauses for things that have changed
(since Cayenne knows this). So, for example, your BLOB wouldn't be sent
to the DB (in the SET clause section) unless you had changed it, but
this has nothing to do with optimistic locking. :-) Optimistic locking
is really about the WHERE clause of the UPDATE (which is determined by
your primary keys and the fields you mark for optimistic locking).
Cayenne being efficient about what it SETs is just Cayenne being
efficient -- and if nothing was changed, no UPDATEs.
This is also why you don't want to optimistically lock on a BLOB (you'd
always have to send the entire BLOB over, even if it didn't change).
And if the BLOB did change and you are optimistically locking on it, you
get to send it over TWICE (original + changed). Imagine that for a
multi-megabyte values. It is far more efficient to compute a 24 byte
(or whatever size) SHA/MD5 hash of the BLOB and only lock on it. Write
a cover method on your setBlob() and re-compute and set the hash when
the BLOB changes. And store BLOBs in a separate table. You'll be
happier and faster. :-)
Also, when you do your commitChanges(), Cayenne is going to update the
snapshot of DB values with what was committed. This is why you can't
rollback past the commitChanges(). What the DB has and what Cayenne has
are in-sync when the commit succeeds. If there is an error, you get the
exception and can handle it as appropriate for your application.
/dev/mrg
-----Original Message-----
From: Gili [mailto:cowwo..bs.darktech.org]
Sent: Thursday, September 01, 2005 11:02 AM
To: cayenne-use..bjectstyle.org
Subject: Re: Yet another optimistic locking question
Oh my. It all makes so much more sense now... So if I understand
it
correctly,
1) We store the perceived DB value somewhere
2) We store the cached (maybe modified) value elsewhere
3) When a commit occurs, we compare the objects in 1 and 2, then issue a
UPDATE only for fields which have changed.
Cool :) This also sounds quite efficient to me.
Thank you,
Gili
Gentry, Michael (Contractor) wrote:
> Optimistic locking never locks the row in the database (it is
> optimistic). Read:
>
>
http://www.objectstyle.org/confluence/display/CAY/Optimistic+Locking+Exp
> lained
>
> It explains how Cayenne can ensure that no changes occurred between
the
> SELECT and UPDATE phase. If you still have questions I'll try to
answer
> them.
>
> Thanks,
>
> /dev/mrg
>
>
> -----Original Message-----
> From: Gili [mailto:cowwo..bs.darktech.org]
> Sent: Thursday, September 01, 2005 12:06 AM
> To: cayenne-use..bjectstyle.org
> Subject: Yet another optimistic locking question
>
>
>
> A question about how optimistic locking is currently
> implemented. Do we
> implement it like this?
>
> 1) Lock row
> 2) Read row
> 3) Compare read row to DataObject version of row
> 4) If values mismatch, unlock the row and throw an exception
> 5) If values match, continue with update and unlock row
>
> or do we not lock the database at all? If we don't lock it at
> all, how
> can we ensure that no changes occur after step 3 but before step 5?
>
> Thank you,
> Gili
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:34:21 EDT