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".
