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

Reply via email to