Actually that's one of the reasons I'd like to use entity beans - so I don't have to roll my own caching...
Rgds, -Paul > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:EJB-INTEREST@;JAVA.SUN.COM]On Behalf Of Baker, Jay > Sent: Friday, November 15, 2002 11:36 AM > To: [EMAIL PROTECTED] > Subject: Re: Which caching strategy to employ ? > > > If this is a dictionary, you might consider not using EJB. You can use > caching solutions that are already out there, so you don't have to roll your > own. > > -----Original Message----- > From: Paul Kavanagh [mailto:paul@;SOFTFACE.COM] > Sent: Friday, November 15, 2002 1:28 PM > To: [EMAIL PROTECTED] > Subject: Which caching strategy to employ ? > > > Hi all, > > I'd like your opinion on which design strategy to employ in the following > scenario: > > I'd like to cache a couple of tables which together contain almost half a > million rows of read-only > data (it's a dictionary containing about 40MB of data). The choices as I see > them are: > > 1. SLSB -> JDBC (via a DAO), implementing my own persistence and caching. > 2. SLSB -> Multiple CMPs with CMR, leveraging the container's persistence > and caching. > 3. SLSB -> One BMP, implementing my own persistence by joining the tables > and using the container > to cache the data. > > In 2 and 3 the beans would be marked Read-only where app. server support is > available. > > I'm using EJB 2.0 with WL 7.0. This design will eventually need to work on > the forthcoming WAS 5.0 > also, so I'm really looking for a design which although I may tweak some > knobs and levers for each > app server, is as portable as possible and uses app. server descriptor > settings to increase > performance. > > Thanks in advance, > -Paul > > =========================================================================== > 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".
