You are thinking too much in terms of real locks. If you have a large entity (lots of columns) then you can save a lot of loading time if you could check to see if the data stored in the EntityContext is still in sync with the db row. Basically you do a select to see if any of the optimistic lock columns (timestamp, sequence, or other junk) have changed. For a lot of entities this would be a huge savings.
-dain Bill Burke wrote: > I don't see how optimistic locking can have optimization advantages with > commit-option B. I thought B's benefit was only for non-transactional > method calls. > > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf >>Of Dain Sundstrom >>Sent: Tuesday, April 09, 2002 10:16 AM >>To: Bill Burke >>Cc: Henri Chen; [EMAIL PROTECTED] >>Subject: Re: [JBoss-dev] RE: Bug in >>EntityMultiInstanceSynchronizationInterceptor.java ? >> >> >>I agree. Commit option B assumes that you can "synchronize the >>instance¡¦s state from the persistent storage at the beginning of the >>next transaction." We simply don't have any method to to that in 2.4.4 >>or the current 3.0 code, other then reload all the data. The optimistic >>locking code that I have planed for 3.0 will allow a quick is changed >>check with the database. So until then option B doesn't buy you much. >> >>-dain >> >>Bill Burke wrote: >> >> >>>Commit option B doesn't give you anything anyways in JBoss >>> >>unless you are >> >>>doing non-transactional requests on your entity beans. Since this is a >>>rarity, I didn't put much thought into commit-b optimizations for the >>>multiinstance interceptors. >>> >>>Bill >>> >>> >>> >>>>-----Original Message----- >>>>From: Henri Chen [mailto:[EMAIL PROTECTED]] >>>>Sent: Tuesday, April 09, 2002 9:46 AM >>>>To: [EMAIL PROTECTED] >>>>Cc: Bill Burke >>>>Subject: RE: [JBoss-dev] RE: Bug in >>>>EntityMultiInstanceSynchronizationInterceptor.java ? >>>> >>>> >>>>Is this implies that there is no Option B in jboss 2.4.4 at all >>>>because option B virtually equals to option C? >>>> >>>>Henri >>>> >>>>-----Original Message----- >>>>From: [EMAIL PROTECTED] >>>>[mailto:[EMAIL PROTECTED]]On Behalf Of Bill >>>>Burke >>>>Sent: Tuesday, April 09, 2002 9:09 PM >>>>To: Henri Chen; [EMAIL PROTECTED] >>>>Subject: [JBoss-dev] RE: Bug in >>>>EntityMultiInstanceSynchronizationInterceptor.java ? >>>> >>>> >>>>This is because we trash the instance. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Henri Chen [mailto:[EMAIL PROTECTED]] >>>>>Sent: Tuesday, April 09, 2002 4:40 AM >>>>>To: [EMAIL PROTECTED] >>>>>Cc: [EMAIL PROTECTED] >>>>>Subject: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? >>>>> >>>>> >>>>>Dear Bill, >>>>> >>>>>Sorry to bother you again. This is based on the jboss 2.4.4 >>>>> >>source code. >> >>>>>According to the ejb 2.0 spec as seen on P.210, in Option B, the >>>>>instance should only be marked as "invalid state" inside >>>>>afterCompletion(). However, the >>>>>EntityMultiInstanceSynchronizationInterceptor.java >>>>>implementation of jboss 2.4.4 always calling ejbPassivate() no >>>>>matter it is Option B or Option C. >>>>> >>>>>Henri Chen >>>>> >>>>> >>>>_______________________________________________ >>>>Jboss-development mailing list >>>>[EMAIL PROTECTED] >>>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>>> >>>> >>> >>>_______________________________________________ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> >> >> >>_______________________________________________ >>Jboss-development mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development