Cedric,
Could you elaborate on why read-only clients will suffer? Are you assuming
that the container is weak enough not to be able to detect readonly access
to a particular cmp bean? Have you got any performance data for the "last
minute check" feature, assuming there has been some change in the bean? I
assume that most databases would access the record/block through the primary
index when the primary key field is referred too in a where clause of the
update statement. The checking cost should then be quite small.
Assuming I am recalling the same post I do not understand how you can refer
to the solution presented as 'half baked'. I know many of Borland AppServer
customers who appreciate this feature and use it appropriately. Please note
that this feature is turned at the bean deployment level and not 'all ejbs'
or 'all txs'.
By the way has BEA a tool that actually shows the ratio of writes/reads that
will happen on rows from a J2EE application deployed in their container. Is
it 1:1?
regards,
William Louth
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Cedric Beust
Sent: Wednesday, June 27, 2001 10:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Are Entity Beans(CMP/BMP) really necessary???
Some good points in that article, but it overlooks some important aspects.
In a nutshell:
- It only covers container-level optimistic concurrency. The alternative
(database-level optimistic concurrency) has its uses as well
- The two-phase SELECT cancels most of the benefits of optimistic
concurrency, and it penalizes read-only clients. If you choose to go for
optimistic concurrency in the first place, you want to be... well...
optimistic. You believe that most of the time, the data you are updating
has *not* been modified, and therefore, that a "last minute check" is
unnecessary, or even unacceptable performance-wise.
But the two-phase SELECT imposes an overhead on *all* EJB's and *all* their
transactions. In that respect, it is a half-baked solution, a choice you
should make when you don't know exactly the ratio of writes/reads that will
happen on your rows. You don't want to go Pessimistic, but you're afraid
that being overly Optimistic will result in too many rollbacks.
No silver bullet there, just trade-offs.
How optimistic do you want to be today? ;-)
--
Cedric
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan K. Weedon
> Sent: Wednesday, June 27, 2001 2:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Are Entity Beans(CMP/BMP) really necessary???
>
>
> For readers who are interested in this topic, I recommend the
> thread titled:
>
> Real-world limitations of simplistic optimistic concurrency
>
> Which can be found at:
>
>
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0009&L=ejb-interest&;
> F=&S=&P=113913
>
> -jkw
>
> "Jonathan K. Weedon" wrote:
>
> > Cedric,
> >
> > Actually, I believe you provide the following:
> >
> > Exclusive concurrency (pessimistic locking at the container level)
> >
> > This cannot be used in conjunction with clustering, and is therefore
> > an unscalable solution.
> >
> > Database based pessimistic concurrency
> >
> > This can be used with clustering, but is not scalable due to excessive
> > locking in the database.
> >
> > Database based optimistic concurrency
> >
> > This corrupts the database, if done without verified updates (this is
> > the point that you made yourself, originally).
> >
> > So, you have a choice between unscalable (pessimistic locking, either
> > in an unclustered container, or in the central database) or incorrect
> > (due to unverified updates).
> >
> > If there is a better option, please explain it. In particular, how do I
> > deploy a scalable application (meaning one that uses optimistic
> > concurrency) on WebLogic without running the risk of corrupting
> > my database (due to a lack of verified updates).
> >
> > -jkw
> >
> > Cedric Beust wrote:
> >
> > > > From: A mailing list for Enterprise JavaBeans development
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan K. Weedon
> > >
> > > > Is such a feature provided in WL6 using EJB 1.1? I did not
> > > > believe so.
> > >
> > > No, we provide either Exclusive concurrency (pessimistic at
> the container
> > > level) or Database (pushed to the database, which can be
> either optimistic
> > > or pessimistic depending on your database vendor).
> > >
> > > None of them corrupt the database (that I know :-)).
> > >
> > > --
> > > Cedric
> > >
> > >
> ==================================================================
> =========
> > > 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".
> >
> > --
> > Jonathan K. Weedon: Architect
> > VisiBroker, Borland AppServer
> >
> > Register now for the 12th Annual Borland Conference: July 21-25 in
> > Long Beach, California. BorCon is the best place to learn about award
> > winning technologies for implementing e-business. Register today!
> > http://www.borland.com/conf2001/
> >
> > This e-mail, and any attachments thereto, is intended only for use by
> > the addressee(s) named herein and may contain legally privileged
> > and/or confidential information. If you are not the intended
> > recipient of this e-mail, you are hereby notified that any
> > dissemination, distribution or copying of this e-mail, and any
> > attachments thereto, is strictly prohibited. If you have received
> > this e-mail in error, please immediately and permanently delete the
> > original and any copy of any e-mail and any printout thereof.
>
> --
> Jonathan K. Weedon: Architect
> VisiBroker, Borland AppServer
>
> Register now for the 12th Annual Borland Conference: July 21-25 in
> Long Beach, California. BorCon is the best place to learn about award
> winning technologies for implementing e-business. Register today!
> http://www.borland.com/conf2001/
>
> This e-mail, and any attachments thereto, is intended only for use by
> the addressee(s) named herein and may contain legally privileged
> and/or confidential information. If you are not the intended
> recipient of this e-mail, you are hereby notified that any
> dissemination, distribution or copying of this e-mail, and any
> attachments thereto, is strictly prohibited. If you have received
> this e-mail in error, please immediately and permanently delete the
> original and any copy of any e-mail and any printout thereof.
>
> ==================================================================
> =========
> 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".
===========================================================================
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".
