c below > -----Original Message----- > From: Evan Ireland [mailto:[EMAIL PROTECTED]] > Sent: 24 October 2001 21:28 > To: Tim Fox > Cc: [EMAIL PROTECTED] > Subject: Re: Server-side data caching > > > 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?
If your data is read-only then nothing. If you're writing to the table too - then you have the classic dirty cache problem - you'll need to ensure cache consistency by some means. (Multi-casting your changes or whatever). So basically I'd use this technique if the data is invariant/ref data (like US states), but not in the general case. > > >>-----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".
