Tim Fox wrote: > 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.
What would be the problem with having multiple copies of the cache? >>-----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".
