> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Georg
> Rehfeld
> Sent: Monday, June 11, 2001 8:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] FW: Busy wait on one thread
>
>
> 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.
>
As of this moment, I'm not working on removing the whole locking business.
So if somebody wants to take it on, please do.
> I assume including the activation of MULTIPLE bean instances?
> 9.1.11 Fig 24.
>
I read the spec, but am confused on how MULTIPLE bean instances work with
commit-option 'B'. Do you still have an instance cache for commit-option
'B' and only grab from this cache when there is no transaction associated
with the method invokation?
> 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.
>
Really cool stuff! This can be easily implemented in CMP/JAWS since JAWS
keeps the old state alive.
Bill
> 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
