dan benanav wrote:
> 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).
>
Agreed. I don't like very much this trick either. But I would still use it if I had to
use
Weblogic.
>
> Does IAS work for bean managed beans as well?
I don't think so, since with BMP, the container doesn't know which fields are
persistent, and since
these fields can be private.
> 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.
>
You can always configure the container to choose the "standard" approach. I don't see,
however, why
it makes the assumption that the bean totally controls the DB (see below).
>
> 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.
>
Agreed. However, this kind of problem can be avoided. I didn't specify all the options
you can use
because I just wanted to show that optimizations existed in many products. Now, since
you raise a
good point, here are all the options you have with IAS:
1. The three levels of caching specified in the specs are supported. Using option A,
you don't have
to call ejbLoad each time a tx begins.
2. There are four different types of optimistic concurrency behaviours :
- updateAllFields : this is the standard behaviour; all the fields are written to
the DB. This
relies entirely on the transaction isolation level to handle the concurrency problems.
- updateModifiedFields : only the modified fields are written to the DB. This is
the default,
and still relies on the DB to handle concurrency problems.
- verifyModifiedFields : only updates the modified fields, but verify that their
value in the
DB is still the same as at the beginning of the tx. This allows not to rely on the DB
to handle
concurrency problems, but doesn't solve the problem you mentioned before.
- verifyAllFields : update all fields, but verifies that their value in the DB is
still the
same as at the beginning of the tx. This allows not to rely on the DB to handle
concurrency
problems, and solves the problem you mentioned before.
Does it make sense?
>
> 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.
>
Except that the "read-only declaration" approach doesn't allow you to update only some
of the
fields. If you have a big BLOB in your bean that never changes, you will still have to
update it
each time. IAS, IMO, allows you more flexibility (but of course, you have to choose
your options
very carefully).
>
> >
> > >
> > > >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!
Agreed.
> 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.
>
Yes, it would be cool. But in a clustered environment, it won't be easy for the
servers to
implement it.
>
> >
> > 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.
>
Yeah, that's what I meant (I'm not a native English speaker, and I understand that my
words can
sometimes be confusing).
>
> >
> > - 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.
>
There is room for enhancements, that's for sure.
BTW, that was an interesting discussion.
Regards.
JB.
>
> >
> >
> > 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".
--
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".
