> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Georg
> Rehfeld
> Sent: Tuesday, June 26, 2001 11:25 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] High load...
>
>
> Hi,
>
> Bill:
> > |- Somebody had a great idea earlier of adding "optimistic locking" for
> > |CMP/JAWS. Along with this feature, you could write a specialized
> > |EntityInstanceInterceptor that did not do "transactional locking" with
> > |commit Option 'A'. This would be great for beans that had
> > |read-only invoked operations 90% of the time.
>
> I suggested that and did take the job implementing it (though I actually
> did no coding yet because I have to earn some money).
>
> Marc:
> > yes, that would be interesting, BUT AGAIN I WANT TO FINISH OFF THE 2.X
> > SERIES WITH THE BUGS REMOVED and the streamlined cache with
> transactional
> > locking.
> > ...
> > WE NEED STABILITY IN FEATURES
>
> Yes, agreed.
>
> My suggestion was intended for the Rabbit Hole and originally
> meant to be used with commit options B/C in case there are
> multiple bean instances when Rabbit Hole is finished.
>
> Multiple instances would be not very usefull with pessimistic
> locking done on the DB, as the pessimistic behaviour (and locking
> waiting without a message) simply would remain viewed from the
> clients perspective.
>
> But maybe Bill is right, OL could be used with commit option A
> and single bean instances too? I'm not really sure ... no I
> don't think so, because then every TX is working on state
> possibly modified by another TX and, even worse, with one
> instance only the optimistic approach (based on the diff of the
> actual beans state and the state before TX.begin) will fail, as
> at commit time the 'old' state has to be set equal to the current
> state and the next concurrent TX committing will succeed, where
> it should see a 'you are too late to commit' exception!
>
Sorry Georg, I don't what planet I was on when I made the "option A with
optimistic locking" comment.
Sort of related, I did a simple test with Oracle 8.1.7 in 2 separate
SQL*PLUS windows. With autocommit off, it seems that if you try to update
the same row in 2 different windows, one window waits until the other
commits. Wonder if this will happen with JDBC as well, I'll let you
know....Anybody know the behaviour on this with other DBs? Is this common
locking behaviour? If so, great!
All in all, I think JBOSS should delegate synching and locking to the DB
wherever it can because the DB is usually more efficient at this. Also,
IMHO, this is really the best way to synch multiple instances of JBoss.
Regards,
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
