Hi,
This comes back to an earlier point I have with some ejb containers. The
"generally accepted approach" is coming from vendors whose solution can only
handle coarse grained beans...they do not have something like CORBA's POA.
Would you design a new system to replace a legacy system based on the legacy
systems design. No. Well I do not either if a container has problem scaling
to a large number of medium sized beans then I swap it out and get something
that can.
you said
"The code required to detect the "change" of the "bean's state" becomes
fairly
complex and thus will add some amount of overhead to the container's CMP
implementation.While this feature is very useful for a lot of systems, I,
personally,
would not want this extra overhead when building really large, high-volume
systems..."
So instead you intend to write it yourself? For every entity bean?
William
> -----Original Message-----
> From: Robert Patrick [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, February 21, 2000 5:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: When to use Entities and EJB [was Re: This should be
> easy ... ]
>
> Hi,
>
> While I like the idea of "automatically detecting the changed state" to
> determine the need to store (or not), this does not come without some cost
> associated with it. If I were to take the (or at least one) generally
> accepted approach for defining my entity beans and define very
> course-grained beans with lots of dependent objects -- in essence, a
> sub-graph of objects whose root is the entity bean instance. The code
> required to detect the "change" of the "bean's state" becomes fairly
> complex and thus will add some amount of overhead to the container's CMP
> implementation.
>
> While this feature is very useful for a lot of systems, I, personally,
> would not want this extra overhead when building really large, high-volume
> systems...
>
> Just my two cents,
> Robert
>
> At 05:22 AM 2/18/00 -0500, you wrote:
> >Hi,
> >
> >The isModified method is something I totally disagree with. I thought the
> >reason for using an ejb container was to off load all of this type of
> work.
> >Remember the less code we write the less likely we will introduce bugs
> >(unless we decide not to implement some business method). The isModified
> >method is specific to Web Logic and should be avoided in keeping with the
> >spirit of EJB. I hate to see such code in a bean. If web logic cannot do
> >this infrastructure work then thats their problem not mine...I will just
> not
> >recommend their server. The IBM flag seems abit better but again I feel
> we
> >will introduce some problems in deployment. What happens if a deployer
> >accidentally flags a write method to read only. Also does this not break
> the
> >golden rule of encapsulation in OO. It appears now that people will have
> to
> >know that some state will be changed by some method call. Remember this
> >state could be hidden and not accessed through accessors but is required
> to
> >be made persistent...thus it is a internal implementation issue and not a
> >interface issue. I think we should let the container do the work in
> figuring
> >out if something has changed since this is the fact and not some
> assumption
> >or configuration.
> >
> >Another problem with the read only flag relates to the implication that
> >something is a write method. In most systems that I have seen built we
> see
> >that the user edits some local copy which then given to a session bean
> and
> >then the entity. Now if the user sends a copy over and nothing has
> changed
> >(the gui did not pick it up) what we will inccur is a database access for
> no
> >reason but because of some flagging issue. I use IAS 4.0 and it supports
> >tuned writes (only write the sql for what has changed) how can the above
> >methods achieve this? enlighten me.
> >
> >William
> >
> > > -----Original Message-----
> > > From: dan benanav [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, February 17, 2000 10:40 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: When to use Entities and EJB [was Re: This should be
> > > easy ...]
> > >
> > > Jean-Baptiste Nizet wrote:
> > >
> > > >
> > > > >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.
> > > >
> > >
> > > The isModified method is OK but the programmer can easily make
> mistakes by
> > > not putting a
> > > setModified call in the correct business methods of the bean. In
> addition
> > > you need to call it
> > > appropriately in other methods like ejbLoad, ejbActivate,
> ejbPassivate,
> > > ejbRemove. That is a
> > > lot of coding to do which is not necessarily so bad, but a mistake can
> > > totally screw you up.
> > > (Remember how using "=" instead of "==" could screw you up in C
> > > programming. Simple little
> > > thing but can cause lot's of bugs).
> > >
> > > Does IAS work for bean managed beans as well? That sounds like a
> good
> > > approach since doesn't
> > > rely on the programmer to correctly identify read-only methods.
> However
> > > it also makes the
> > > assumption that the bean is not shared and totally controls updates to
> the
> > > db. Hopefully you
> > > can specify not to use that.
> > >
> > > Suppose for example you have the following scenario and optimistic
> > > concurrency is used. A
> > > method call "foo" on the bean generates a number from one of it's
> > > fields, call it "x" and
> > > from one input, let's call that "y", and replace x with the new value.
> > > public void foo(int y){
> > > x = f(x, y);
> > > }
> > >
> > > What if two method calls to foo occur simultaneously to the entity
> object
> > > and two bean
> > > instances handle the calls concurrently. In the first case foo is
> called
> > > with y=3 and in the
> > > second call y=4. Suppose that x = 1 at the beginning of both calls and
> > > that f(1, 3) = 4 and
> > > that f(1, 4) = 1;
> > > You have set things to TRANSACTION_SERIALIZABLE and are relying on the
> > > database to generate an
> > > error. In this case however it won't becuase the second call doesn't
> > > change the data in the
> > > database and so no additional updates occur.
> > >
> > > For Oracle this is realistic since TRANSACTION_SERIALIZABLE doesn't
> block
> > > the call it merely
> > > generates an error when you try to update something that was changed
> in
> > > another transaction
> > > since the transaction began.
> > >
> > > It may be better to use the declare "read-only" approach.
> > >
> > > >
> > > > >
> > > > > >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.
> > >
> > > But that will certainly make it hard for bean providers! Also there
> is
> > > another way. Allow one
> > > to specify that a method should be synchronized, meaning that it
> should
> > > serialize calls to the
> > > method. Then the bean can be optimized in the best way.
> > >
> > >
> > > >
> > > > 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
> > >
> > > Wouldn't be good enough. For read only methods you want optimistic and
> for
> > > update methods you
> > > want pessimistic.
> > >
> > > >
> > > > - automatically detect if a store is necessary or not
> > >
> > > >
> > > > - automatically detect which fields must be updated
> > >
> > > Declaring "Read only" may be better.
> > >
> > > >
> > > > - let you specify if the DB is shared or not (to avoid unnecessary
> > > loads)
> > > > - ...
> > >
> > > All my statements and conclusions were based on the current state of
> the
> > > EJB spec and the state
> > > of most current application servers. I didn't make that clear in my
> > > original email.
> > >
> > > >
> > > >
> > > > 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".
> >
> >
> >***********************************************************************
> >Bear Stearns is not responsible for any recommendation, solicitation,
> >offer or agreement or any information about any transaction, customer
> >account or account activity contained in this communication.
> >***********************************************************************
> >
> >=========================================================================
> ==
> >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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
