Hi,
I like your idea for optimistic locking, however I think generally you need
to check that -no- fields have been changed, not just the ones you changed.
These are two different behaviors, sometimes you want one and sometimes
the other, but I think as a default you are more likely to want the -no-
fields changed option. This is more like what versioning db's such as
interbase/firebird do.
david jencks
On 2001.06.11 08:48:57 -0400 Georg Rehfeld wrote:
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
