What about using JNDI for caching server side object?
http://www.weblogic.com/docs51/classdocs/API_jndi.html#caching -----Original Message----- From: Tim Fox [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 24, 2001 9:57 AM To: [EMAIL PROTECTED] Subject: Re: Server-side data caching This may work in practice - specifically (and probably only if) your ejbs are all running in the same JVM. This will probably be true in most cases - but there is nothing in the spec. that prevents an EJB server from using multiple JVMS, or even clustering across multiple machines - in those cases you are going to have problems with this approach. > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Victor Langelo > Sent: 23 October 2001 21:10 > To: [EMAIL PROTECTED] > Subject: Re: Server-side data caching > > > Ken, > > Assuming this is read only data, I would use a stateless session > bean that loaded > that table and saved it in a static collection. I know that > static attributes are > supposed to be final, but I cannot see nor have I experienced any > problem using this > technique. Read the table whenever the attribute is null (or an > empty collection if > you initialize it). That way you won't need a static initializer > which might cause > problems in some servers. > > You can follow the letter of the spec by declaring the attribute as: > > final static List usStates = new ArrayList(); > > --Victor > > > "Kenneth D. Litwak" wrote: > > > If I wanted to have the equivalent of a whole table of data, > liek the names of > > U.S. states, cached in a J2EE application, liike in the EJB > container, and I > > wanted this data available to every EJB that wanted it, what > would be a good > > design approach? A plain Java object implemented as a > SIngleton? A stateful > > session bean with ahandle taht any caller could lookup and use? > If the latter, > > how would you get around the restriction against multiple > callers on an EJB? > > Thanks. > > > > Ken > > > > ================================================================== > ========= > 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".
