Dan, I offer my advice not as a criticism of you personally but as simply a response to your posting. Please don't take this personally, lists like this are meant for debate which means that your ideas will be challenged. See below for my reply ... Richard 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". General remarks like the one above are more important then people realize. They are like the morals upon which laws are written. With out generalizations you have no philosophical foundation upon which to construct rules, contracts, and implementations. > 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 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. Here is the source of the problem. The truth is each EJB server will implement synchronization with the database (in the case of entity beans) differently. The specification does prescribe 3 commit options each of which requires that an ejbStore be performed at the transaction commit time, but I believe that we have some flexibility with this. In the case of bean-managed persistence you would have to use isDirty flags to avoid a sync. This can not be avoided, but we don't need a specified mechanism for handling isDirty, that's the responsibility of the bean developer who is by definition responsible for database reads and writes. In container-managed persistence the onus is on the container to synchronize the bean's state with the database. I interpret the specification as stating that the beans state must be synchronized with the database. If no changes occurred to the bean instance, my CMP would not bother to do write data to the database. (I'm developing a EJB server for someone that's why I say "my CMP") because I would conclude that the state is already syncronized. With the next transaction or method invocation I would, however, re-load state from the database. Perhaps the specification should be changed to provide vendor's a more flexible interpretation, but my guess is that they will implement more intelligent synchronization for CMP anyway. > 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? Again, this assumes that you know the behavior of my EJB vendor, which you do not. My vendor, who is me in this case, implements behavior that does not write data to the database if no data was changed by the client. > 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? In a medical setting I would want my bean's state refreshed with every new transaction so that I can keep up with the latest changes in data. This is critical in many situations. Imagine a scenario where a patents data is not refreshed before each read. In this case a doctor might change a patients diagnosis just before a pharmacists reads the prescription for drugs based on the previous diagnosis. If the pharmacist is unaware of a change, counter indications might aggravate the patients illness or even cause death. > > > 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". -- Author of Enterprise JavaBeans Published by O'Reilly & Associates EJB FAQ http://www.jguru.com/faq/EJB EJBNow.com http://www.ejbnow.com
