Hi Robert,
        What do U suggest is better for an application which does an intensive
reading from the data source?
Nittile Gupta.

>----------
>From:  Robert Patrick[SMTP:[EMAIL PROTECTED]]
>Reply To:      A mailing list for Enterprise JavaBeans development
>Sent:  Monday, December 06, 1999 8:44 PM
>To:    [EMAIL PROTECTED]
>Subject:       Re: Transaction isolation level useless at the ejb server
>level ?
>
><<File: ATT00104.html>>
>At 04:57 PM 11/29/99 -0800, you wrote:
>
>> > Serial reuse of the same instance would adhere to the
>> > principle that there are
>> > never two threads executing in the same instance at the same
>> > time. It would be
>> > equivalent to use of pessimistic locking with exclusive locks
>> > even for read-only
>> > access so would be an unsatisfactory designpoint for a
>> > server. I suppose it may
>> > be a useful deployment option in some bizarre situations!
>>
>>Weblogic uses this pessimistic locking approach.
>>
>>I think this is an unacceptable approach for an EJB server. I don't know
>>if all bean developers using an EJb server with such forced pessimistic
>>locking realize that the beans are getting locked for reads.
>
>The issue of whether to use pessimistic locking or optimistic locking
>is a
>trade-off.  Pessimistic locking can severely reduce concurrency in
>"mostly
>read-only" and/or "low data contention" situations.  However,
>optimistic
>locking suffers from its own problems, especially in update-intensive
>applications where data contention is high.  The container ends up
>doing
>deep copies of the object graph and allowing the operations to proceed
>just
>to have them fail at commit time...
>
>In other words, no single solution is right for every application.
>
>Just my two cents,
>Robert
>
>

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to