Like I said before, "mostly read" applications will benefit from optimistic
locking.
At 10:23 AM 12/7/99 +0530, you wrote:
>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".
===========================================================================
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".
