Hi everybody
I am currently facing the design of a web application adhering to the EJB programming model. I want implement a caching mechanism to speed up access to mostly read-only data . The idea is to model it in the ejb TIER ; SLSB would access a java singleton helper class implementing the caching logic . Further it is not a requirement that just one instance of that singleton lives in the system ( in a clustered environment I want one instance of that singleton running in each logical/physical node.
The problem is to well understand what kind of problem exist having singleton (static variables) in the EJB tier.
Does the EJB spec. deprecate singleton usage?
Is it a problem use synchronization mechanismsin a singleton java jhelper class running in the EJB tier?
Thanls a lot in advance for your help
claudio.

Claudio:

    Why reinvent the wheel, my suggestion will be to use existing framework for your caching mechanism and leave all set of caching problems for framework.

I will like you to point to

Java Caching System

This is a subproject of Turbine and is available on jakarta site.

some of the high points are listed below.

JCS is a distributed caching system written in java for server-side java applications. It is intended to speed up dynamic web applications by providing a means to manage cached data of various dynamic natures. Like any caching system, the JCS is most useful for high read, low put applications. Dynamic content and reporting systems can benefit most. However, any site that repeatedly constructs pages, dropdowns, or common search results form a database that is updated at intervals (rather than across categories continuously) can improve performance and scalability by implementing caching. Latency times drop sharply and bottlenecks move away from the database in an effectively cached system.

The JCS goes beyond simply caching objects in memory. It provides several important features, necessary for any Enterprise level caching system:

Memory management
Disk overflow (and defragmentation)
Element grouping
Quick nested categorical removal
Data expiration
Extensible framework
Fully configurable runtime parameters
Remote synchronization
Remote store recovery
Non-blocking "zombie" (balking fa ade) pattern
Optional lateral distribution of elements via HTTP, TCP, or UDP
Remote server clustering and failover (almost complete)
These features provide a framework with no point of failure, allowing for full session failover including session data across up to 256 servers.


Regards
Chetan

Hi Claudio,

You might want to also check out this Singleton Example based on Tangosol's Coherence.

Later,
Rob Misek
Tangosol, Inc.
Coherence: Cluster your Work. Work your Cluster.