What approaches do others use in the case where it is acceptable for users to view stale data? 1. One approach is to use the "Supports" transaction attribute (assuming the app server follows the spec and does an ejbLoad() between ejbActivate() and the first business method!). 2. Another approach would be to code in lazy initialization into the business methods (i.e., follow the spec's suggestion that the business methods go directly to the database). 3. A third approach is to just set all transaction attributes to "Required". I like option 1 best, because: a) it is non-intrusive; b) if it is later deemed that stale data is unacceptable, one can just change the transaction attribute without touching the code; c) it is (potentially) less expensive than the option 3, if the implementation just calls ejbLoad() once; d) one could use the same bean in two different applications, one where stale data is acceptable and one where it isn't. A drawback of (1) is that it is possible that a bean could hang out for a very long time without ever being refreshed -- any solutions to this problem? So ... what approaches do others use in the case where stale data is acceptable? What do you see as the trade-offs? In general, are there any good sources that give examples of real-world applications where one would choose some of the transaction attributes other than "Required"? Laurel -----Original Message----- From: Vance Christiaanse [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 9:51 AM To: [EMAIL PROTECTED] Subject: Re: Unspecified Transaction Context Victor, There is a footnote in the first paragraph of 9.1.7.1 that includes "Never" and "Supports". 9.1.7.1 does say that ejbLoad and ejbStore should typically be no-ops for an entity bean used in an unspecified transaction context and that the business methods should go directly to the database for the latest data. But it does guarantee that once a new entity instance is created, ejbLoad will be called before the first business method. (But not necessarily before each business method.) So... it looks to me as though the behavior Laurel Neustadter reports is inconsistent with the spec. Vance Vance Christiaanse Victor Langelo wrote: > > The title for Section 9.1.7.1 is "ejbLoad and ejbStore with the NotSupported > transaction attribute." I think you're trying to read this section out of > context. It only applies when the method's transaction attribute is NotSupported > and doesn't necessarily apply to Supports without a transaction. > > --Victor > > Laurel Neustadter wrote: > > > Hi: > > > > Section 9.1.7.1 of the EJB 1.1 spec specifies: > > "The following are the only guarantees that the Container provides for the > > instances that execute the methods with an unspecified transaction context: > > The Container invokes at least one ejbLoad between ejbActivate and the first > > business method in the instance. The Container invokes at least one ejbStore > > between the last business method on the instance and the ejbPassivate > > method." > > I am using the 1.2.1 version of the reference implementation. I have coded > > an entity bean where each getter has a transaction attribute equal to > > "Supports". A session bean calls one of these getters without a transaction > > (i.e., with an unspecified transaction context). ejbActivate() is called on > > the bean implementation, and then the getter (i.e., a business method) is > > called. ejbLoad() is never called between ejbActivate() and the business > > method.This seems inconsistent with the quote above. > > Is this a bug in the RI? Or am I misinterpreting the spec? > > Thanks. > > > > Laurel > > > > =========================================================================== > > 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". =========================================================================== 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".
