Persistence operations of entity EJB's are mapped to (jta) transaction boundaries. This is by definition, since the EJB container is not a resource manager itself. The ejbStore method must therefore be called at the end of a jta transaction. The spec is very clear regarding the lifetime of a transaction in relation to http requests:
J2EE 1.3: "J2EE.4.2.2 Transactions in Web Component Life Cycles Transactions may not span web requests from a client. A web component starts a transaction in the service method of a servlet (or, for a JSP page, the service method of the equivalent JSP page Implementation Class) and it must be completed before the service method returns. Returning from the service method with an active transaction context is an error. The web container is required to detect this error and abort the transaction." The classical approach for what you are trying to achieve is to use the http session or a SFSB. Entity beans are transactional. They may provide cached read-only access for none-transactional requests, but updates must be propagated to the resource manager (assuming that the resource manager is transactional) before the end of the jta transaction. /Johan -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Ron Bennett Sent: den 10 februari 2002 05:44 To: [EMAIL PROTECTED] Subject: EntityBean Caching Does an EntityBean synchronize with the database when get methods are called in Mode B caching? I'm trying to determine which caching mode to operate in. I require fault tolerance and clustered load balancing. That has pushed me into using EntityBean EJB. The specification allows three modes of caching. I desire caching of the entity in memory to improve performance of read only operations (i.e., get methods) following an ejbStore(). Although there are no other applications operating on the data (e.g., batch), I am running in a clustered environment. Mode A of caching does not support clustering. Mode B and C do. However, Mode C does not cache the entity. It flushes the entity upon completion of the transaction. I also would like to avoid putting data into HttpSession or a stateful SessionBean while capturing data across multiple screens. It takes several screens worth of capture before I want to persist the information. My preference is to change the state of an EntityBean over several HTTP Requests (Architecture is typical Servlet/JSP layer that talks to an EJB layer using the delegate, session fa�ade and composite entity patterns.) without persisting the EntityBean until the last screen of the unit of work is done. Therefore, I set the beginning of the transaction during processing of the first screen and commit upon the entry and validation of the last. Mode B seems to be the best caching option. It performs an ejbLoad upon the beginning of the transaction and caches state in memory during and after the transaction is completed. What I am uncertain about is whether ejbLoad is called when I execute a read-only method (i.e., get method) on the entity outside the context of a transaction. I really want a Mode A that is capable of clustering, or a Mode B where I know there are no other applications operating on the data - I want a hybrid of A & B, I think. I need to cluster, but I know I'm the only application operating on any given column in the data store. The cloning process should assure that my EntityBean can be cached without having to synchronize with the data store ever. Seems to me this would be a common requirement. I'm using WebSphere 4.02, if that matters. I'd like to hear others thoughts. =========================================================================== 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".
