<vendor>
Jean-Baptiste,
I appreciate the plug, but I want to consider the one limitation you
point out in IAS:
> We will (hopefully) have soon EJB servers which
> - let you choose between optimistic and pessimistic concurrency
> - automatically detect if a store is necessary or not
> - automatically detect which fields must be updated
> - let you specify if the DB is shared or not (to avoid unnecessary loads)
> - ...
>
> In fact, IAS already does all that except for the first point. (Yeah, yeah, I like
>IAS ;-))
Implementing pessimistic concurrency on top of a system which provides
optimistic concurrency is pretty trivial. (The converse is very much
not true, by the way.) So, I would be happy to add this functionality
to IAS but...
I have not noticed anyone discuss the HUGE problem with pessimistic
concurrency, which is dead-lock. If I have two clients, one which
accesses bean A and then bean B, and another which access bean
B and then bean A, these two transactions will probably dead-lock
the server.
Detecting this dead-lock (particularly in the case of a distributed
system, with A and B running in different EJB containers, possibly
from different vendors) is extremely hard, to put it politely.
Perhaps a solution here is transaction timeouts. I am curious if
others have experience with breaking these types of deadlocks in
real systems. (Not just in a database, where it is much easier to
"know everything", but in a distributed system.) And, are people
willing to wait for a timeout to expire to be able to continue using
those beans. I doubt it.
Again, we could easily add the feature you request, but I am not
convinced you will be so happy when the system comes to a screeching
halt.
-jkw
</vendor>
Jean-Baptiste Nizet wrote:
>
> dan benanav wrote:
>
> > Richard,
> >
> > I presented a very simple example of an Account bean and analyzed how one would
> > implement an increment(int x) method. I specifically avoided "general" remarks
>like
> > "Entity beans represent data and behavior".
> >
> > My conclusion was that to implement the increment method I would like to have
>calls to
> > the increment method be serialized and that pessimistic concurrency achieves that.
> But
> > since pessimistic concurrency is not standard the situation becomes more
>complicated.
> >
> > In addition, I said that I would be tempted to not have read only methods in the
>Account
> > object (for example to return the account detail) because of the inefficiency of
>the ejb
> > load-call business method-ejbStore cycle. I want to have a way to declare certain
> > methods read only to avoid the extra call to the database.
> >
>
> >From what I understand, this is exactly the kind of optimization on which EJB
>servers can
> compete. Whether all the possible optimizations should be in the specs or not is an
>open
> issue, but what is sure is that these kinds of optimizations already exist in
>several EJB
> servers.
> For example, Weblogic allows to specify an "isModified()" method; IAS can
>automatically
> detect if the bean state changed since the beginning of the tx and only update the
>fields
> that have changed, and (I think) WebSphere allows you to specify a method as
>read-only. Of
> course, your code and designed can be influenced by the EJB server you choose.
>
> >
> > >From a programming point of view I agree with you. I would prefer to put the read
> > methods in the Entity bean. However given the current state of the EJB spec if I
>want
> > to avoid the extra SQL calls I might be tempted to use a stateless bean for read
>only
> > methods.
> >
> > Also, pessimistic concurrency means that read only methods will block, but really
>that
> > is probably not so bad. It might be bad if lots of things happen to be reading the
>same
> > object often.
> >
>
> Once again, you have the choice here. Weblogic will use pessimistic concurrency
>whereas IAS
> will use optimistic concurrency. Here again, your code will change depending on the
>choice
> you make (which is a bad thing). For IAS, you will probably have to write more
>exception
> handling code, but your performance will probably be better.
> If your goal is to be able to port your application to any EJB server, then you will
> probably have to code everything for the worst case, and hope that the spec leaves
>as few
> holes as possible, but that will also leave less place for optimization, performance
>and
> innovation.
> IMO, given that EJB1.1 is quite new and that most EJB servers will continue to
>evolve and
> offer more and more choices for optimization, I would not code for the worst case.
>We will
> (hopefully) have soon EJB servers which
> - let you choose between optimistic and pessimistic concurrency
> - automatically detect if a store is necessary or not
> - automatically detect which fields must be updated
> - let you specify if the DB is shared or not (to avoid unnecessary loads)
> - ...
>
> In fact, IAS already does all that except for the first point. (Yeah, yeah, I like
>IAS ;-))
>
> Best regards.
>
> JB.
>
> >
> > So the problem is that pessimistic concurrency is what I want for "mutators" and
> > optimistic concurrency is what I want for read only methods. Furthermore read only
> > methods have to go through the ejbLoad-> call method -> ejbStore cycle even though
>no
> > store is required.
> >
> > I would like to hear more specific criticisms to my conclusions. Remember also
>that all
> > my remarks were based on the current state of the ejb spec (namely 1.1) not on what
> > might be if the spec improves.
> >
> > Take your Patient example below for example. Do you care that read only methods
>(even
> > one returning data for just that one patient) on such a bean would have to visit
>the
> > database twice? What about the fact that read calls will block on the same object
>if
> > pessimistic concurrency is used? If pessimistic concurrency is not used then how
>would
> > you handle the problem of serializing calls to the mutator methods?
> >
> > dan
> >
> > Richard Monson-Haefel wrote:
> >
> > > The idea that entity beans should only be used for updates is misguided.
> > >
> > > Entity beans (enterprise beans) represent data and behavior. The behavior part
>is
> > > important to this discussion because it justifies the use of both accessor and
> > > mutator (update) methods in the bean's remote interface. Limiting entity beans
>to
> > > only mutator methods reduces them to data objects, not business components. As
>a
> > > business component, an entity bean represents the full spectrum of behaviors
> > > associated with a persistent business concept. An entity bean that represents a
> > > Patient, for example, provides methods for reading the patient's benefit data
>while
> > > processing a claim; reading a patient's medical history for counter indications;
> > > determining a patient's preferred care provider for scheduling appointments, etc.
> > > If you remove the behavior for accessing data from an entity, you loose the
>ability
> > > to manage a patient individually. EJB allows thousands of client applications to
> > > concurrently manage entity business objects individually. This is what makes
>entity
> > > beans so powerful. Without it, you're better off using something like JDBC
> > > directly.
> > >
> > > There are many situations where the use of enterprise beans is inappropriate. If
> > > your system presents lists and tables of data representing many entities for read
> > > only access, then you should consider using a mechanism other than EJB. For
> > > example, a commercial web site that is used for shopping, like Amazon.com or
> > > eToys.com, would not use EJB to populate web pages with product information in
> > > response to customer navigation and searches. A better approach in this
>situation
> > > is to access the data more directly from Servlets using JDBC (proper connection
> > > management is assumed). When, however, the client is processing a purchase,
>which
> > > is a task applied to an individual purchase order, EJB should be used. (EJB
>might be
> > > accessed indirectly by clients through Servlets.) In this scenario a stateful
> > > session bean might be used to represent the client's shopping cart, while entity
> > > beans represent the client, the chosen products, and the order itself.
> > >
> > > A hospital system, on the other hand, would use EJB every time a Patient record
>was
> > > accessed so that the behavior (both declarative and business logic) could be
>applied
> > > in the context of an individual's data. This is important when reading/updating
>data
> > > specific to an individual. If, however, you needed to generate reports on all the
> > > patients you would not use EJB. Instead of EJB, use a reporting product;
>something
> > > that is designed to search, filter, and organize data for reporting. In the
>medical
> > > system, EJB ensures that very large user populations can concurrently manage
> > > thousands of individual patients safely and appropriately -- it's not a reporting
> > > tool.
> > >
> > > EJB is not a silver bullet; it's only one part of a complete solution. The use
>of
> > > both JDBC and EJB from Servlets, as illustrated in the shopping cart scenario,
>is an
> > > example of how to properly use EJB in the context of a larger solution. EJB is a
> > > powerful new weapon in our enterprise arsenal. Use it properly, within the
>right
> > > context, and it will serve you well.
> > >
> > > If you find yourself making component design decisions that are counter to the
>EJB
> > > programming model -- like using entity beans for updates only -- then you should
> > > reevaluate your entire architecture because you are probably using EJB
> > > inappropriately.
> > >
> > > Thanks,
> > >
> > > Richard
> > >
> > > --
> > > Author of Enterprise JavaBeans
> > > Published by O'Reilly & Associates
> > >
> > > EJB FAQ
> > > http://www.jguru.com/faq/EJB
> > >
> > > EJBNow.com
> > > http://www.ejbnow.com
> > >
> > > ===========================================================================
> > > 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".
>
> --
> Jean-Baptiste Nizet
> [EMAIL PROTECTED]
>
> R&D Engineer, S1 Belgium
> Excelsiorlaan 87
> B-1930 Zaventem
> +32 2 714 45 42
>
> ===========================================================================
> 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".
