Can anyone tell me in brief what is the conclusion for this whole discussion
, i wondering to know about what is the way to do the transaction as dan
specified.
--asha
-----Original Message-----
From: Louth, William (Exchange) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 16, 2000 8:19 AM
To: [EMAIL PROTECTED]
Subject: Re: When to use Entities and EJB [was Re: This should be easy
... ]
you said "Of course, your code and designed can be influenced by the EJB
server you choose"
This is the issue I am facing now. For the last 6 months I have been using
the Inprise Application Server and recently took on some more work for a
client who intends to use Web Logic 5. I loved working with the IAS because
I did not have to do much of the work,it did not get in the way of my code
i.e. no vendor specific code, and performance was great. Now with this
client I have found that to achieve any sort of performance I must use
properitary code i.e. isModified(), to lookup the jndi I must use vendor
specific code in my beans. Things i took for granted are just not there like
proper serialization of home references and so on. Now that I see the state
of play I realize that in fact IAS 4.0 is properitary in this circumstances
since my 100% non-specific vendor code will only run in one container....
IAS 4.0. I am currently looking more into Gemstone and WebSphere and have
found similar things...
note I refer to ejb1.1 containers.
William
> -----Original Message-----
> From: Jean-Baptiste Nizet [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, February 16, 2000 2:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: When to use Entities and EJB [was Re: This should be
> easy ...]
>
> 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".
***********************************************************************
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".
