1 Reply Latest reply on Nov 21, 2006 4:26 PM by Vickj Fisherboss

    Singleton EJB

    Alexander Hachmann Newbie

      Hello,
      I realized, that the Singleton Pattern seems not to be such a common one.
      I tried the workaround with the Poolsize.

      This is my jboss.xml:

      <?xml version="1.0"?>
      <jboss>
       <enterprise-beans>
       <session>
       <ejb-name>SessionLogCacheImpl</ejb-name>
       <configuration-name>Standard Singleton Stateless SessionBean</configuration-name>
       </session>
       </enterprise-beans>
       <container-configurations>
       <container-configuration extends="Standard Stateless SessionBean">
       <container-name>Standard Singleton Stateless SessionBean</container-name>
       <container-pool-conf>
       <MaximumSize>1</MaximumSize>
       <strictMaximumSize>true</strictMaximumSize>
       </container-pool-conf>
       </container-configuration>
       </container-configurations>
      </jboss>


      But this does not work properly.

      I need this singleton for the reason that i want to store objects in a single set from every Client. First I tried to use static sets. This worked out.
      But i read that static should not be used in EJB.
      Forther more this EJB has a timer. So when I have more than one EJB in the pool, the Timer will be called more than once.

      The only way i see to get this working is using singleton. But aint getting this to work.

      Has anyone any suggestion?

      Thanks for your Help,
      Alexander

        • 1. Re: Singleton EJB
          Vickj Fisherboss Newbie

          Are the objects in the "single set accessed by all clients" ever persisted? If so, the DB itself should be your single set accessed by all clients. Then you can allow any number of EJB instances from a pool to access the same DB table(s) at the same time. For reading, you don't care how many readers there are. If multiple writers are creating new objects, that's ok - different ids will be assigned to each by your id generation strategy. If multiple writers are attempting to update the same object at the same time, you need to use optimistic locking (by a timestamp or version attribute) or pessimistic locking (rarely used) to prevent losing changes.

          Forcing all activity to go through a single EJB is not scalable performance-wise and may also may cause memory issues if the set grows too large.

          Good luck!