EJB design: caching in the ejb tier using singleton

  1. 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
  2. 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.

  3. Hi Claudio,

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

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