From: Jay W. <jwa...@ne...> - 2001-06-26 17:26:07
|
That is standard locking, you should see that everywhere unless you can set some bit to not wait for locks and just abort the statement. SQL*Plus and JDBC both look the same to the server. Of course with Oracle it won't block readers, with some other databases you will block readers in the second window as well as writers unless you are at the whatever isolation level supports dirty reads. Cheers Jay -----Original Message----- From: Bill Burke [mailto:bi...@bu...] Sent: Tuesday, June 26, 2001 12:59 PM To: jbo...@li... Subject: RE: [JBoss-dev] High load... > -----Original Message----- > From: jbo...@li... > [mailto:jbo...@li...]On Behalf Of Georg > Rehfeld > Sent: Tuesday, June 26, 2001 11:25 AM > To: jbo...@li... > 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 Jbo...@li... http://lists.sourceforge.net/lists/listinfo/jboss-development |