Title: RE: Which caching strategy to employ ?

Take a look at JCS ( Java Caching System ) over at the Apache project.  There is no production release and I've never used it so be cautious.  There are a few commercial J2EE-ready caching engines on the market also.  Search the archives of this list because some of them were announced on here ( maybe 6 or 9 months ago ).

James Hicks

-----Original Message-----
From: Paul Kavanagh [mailto:[EMAIL PROTECTED]]
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".

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from all computers.

Reply via email to