Has anyone implemented or thought of implementing optimistic
locking with CRC checking? A quick search of the forums didn't
yield anything. I have the typical case where there are a lot of
legacy apps writing to the DB that no one is going to change.

It seems like it'd be pretty simple to do on top of Hibernate--just
a get with a lock while I computed the CRC--but I'd like to put it
inside of Hibernate. Has anyone on the Hibernate team considered
this as a feature before?

thanks,

robert

Write a PropertyAccessor, and map it with the <version> tag.

Thats a cool application of PropertyAccessor, I might blog about this!

Actually, I'm wrong.


Explain to me where you want to keep the "old" CRC value when your objects are detached.

Couldn't you keep it in a property just like version? But that makes you miss the "increment" part of version I suppose.

Yes, if you kept it in a property, then all you would need is some way to "increment" version numbers with custom code. Currently VersionType only takes the old version number in the increment method, so some extra hook would be needed. (Its trivial, of course.)

I'm still considering options. I'd prefer to make it transparent to the
app, but proxies have their own little bits of baggage. It's either got
to go on the object or be associated with it in the cache, I suppose.

-r

I'm still just getting my feet wet with Hibernate, but the heart
of the problem is that on update you have to go back to the DB
with a "select for update" to lock the row while you compute the
CRC of the current value in the DB and compare it to the original
value on the returning object. It doesn't really seem to mix and match
well with version.

I looked through the 2.1.6 code to track where version was handled and
it fits into the general flow quite easily. It would be tougher with a
CRC model since you couldn't batch for one thing.

The other difficulty would be to try and replicate version WRT
collections. As it is now, version operates exactly the way I'd expect
it to: versions are incremented when the set changes, but not when
a value of one of the members of the set changes. (Really nice job
there, in general). With CRCs you rely on locking to stop the race
condition between your read and the subsequent update. This gets
a little tricky with relationships.

My $.02 (USD),

-r

Out of curiosity, why do you want to do CRC checking at the application layer?

Where else could you put it? It's about the only place I have that sort
of control over. It would be best if I could tuck it away into the DB, but
that's not feasible in this case.

-r

I mean, why don't you trust the network layer to communicate data correctly, your hard disks and RAM to store data reliably, and so on? Nowadays, pretty much every layer of the hardware stack implements data reliability safeguards.

I don't see the business/technical need for CRC data checks?

It's an not uncommon alternate implementation of optimistic locking.
I have the typical need for it on this project: lots of legacy applications
(Cobol, Uniface) that aren't going to get upgraded to make them
version-aware. So, you do something like this:

1. Serialize the object that you retrieve from the DB and compute
a CRC (or other checksum, MD5 if you really want to be certain) and
attach it to the outbound object.

2. At some point, you get the object back for an update, so you lock
the row that you're updating (e.g., select ... for update), retrieve a fresh
object from the DB, serialize it, and compute the checksum for the
current set of values.

3. If the checksum of the object you just retrieved matches the
checksum of the object you just got back for an update, write the
new values to the DB. If not, throw a stale data exception.

There are a lot of drawbacks to this method, but sometimes
circumstances force you to adopt the less-than-optimal solutions.

-r

I have to correct myself here: It'll have to be a visible property as
it'll have to be serializable.

So, there are only two key differences from version:

- It's a derived property, so it doesn't correspond to a column.

- You have to do a fresh read from the DB, with lock, prior to
update.

You could forgo the lock when you make a fresh read and just
accept the transaction isolation level set on the connection. MySQL
select ... for update only upgrades the isolation level to repeatable
read. I think it's the same for Oracle. Unless you set it to serializable,
you still have a race condition between the read and the write.

-r

Interesting! I haven't encountered this before and appreciate the explanation.