Hi Bill,

> I've rewritten EntityInstanceInterceptor a little(see my race condition
fix
> email please) and put it some code so that LOCKING-WAITING isn't printed a
> zillion times.  I also added a Thread.yield() before continue; in the
> lock-do-while-loop.

nice to hear that.

> I've also started looking into ditching the do..while loop in favor of
> wait/notify.  It's much more complicated than I originally anticipated,
but
> I'm making progress.  IMHO, the whole locking business should be ditched
> when you have commit-option-C.  Let the database to the synching for you
> with the select-for-update feature(CMP) or make the BMP developers handle
> the locking.

I assume including the activation of MULTIPLE bean instances?
9.1.11 Fig 24.

And then, don't forget about optimistic locking behaviour, which
would help a lot when many clients mostly access beans concurrently
for read only purpose. Optimistic locking (sort of) can be mimicked
with relational DBs that don't have it built in by using a where
clause in update/delete that not only specifies the PK values (or
the rowid) but also all changed fields with their OLD values.

A CMP/JAWS impl would require the old state to be saved and
generating dynamic WHERE SQL clauses based on the diff. BMP
developers have to do it similar by hand.

Sample for readers unfamiliar with SQL (nobody here):

bean fields: pk, name, address; address changed, old state known
generated SQL:

update bean
set    address = <new value>
where  pk = <pk value>
AND    address = <old value>

This way the SQL can only update 1 row, when nobody has concurrently
modified the changed fields, if statement.executeUpdate() returns
0 it must be interpreted as a concurrent modification coming too
late and the TX must be rolled back.

Another variant could use a time stamp field similarly.

regards
Georg
 ___   ___
| + | |__    Georg Rehfeld      Woltmanstr. 12     20097 Hamburg
|_|_\ |___   [EMAIL PROTECTED]           +49 (40) 23 53 27 10



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to