Singleton via deployment descriptor ?

Discussions

EJB design: Singleton via deployment descriptor ?

  1. Singleton via deployment descriptor ? (9 messages)

    Hi,

    is it possible to provide a singleton in a J2EE application
    in the following way:

    implement a SLSB class with e.g. a hash table as member variable
    and business methods for get/put to this hash table.

    force the application server to instantiate this SLSB once and only once
    by application server specific deployment descriptor settings

    e.g. for BEA in weblogic.ejb-jar.xml:
    <stateless-session-descriptor>
    <pool>
      <max-beans-in-free-pool>1</max-beans-in-free-pool>
      <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
    </pool>
    </stateless-session-descriptor>

    Is there any draw back to this solution ?

    Is it J2EE conform, even if the way how to do the above settings
    is application server specific ?

    Thanks for your help
    Barbara

    Threaded Messages (9)

  2. singleton in J2EE application[ Go to top ]

    I woudld not prefer this way of working; "singleton-ness" is a programmers choice, not a deployers choice. I think this is a very important distinction.

    Why don't you make a real singleton (static), and let the ejb look it up?

    class Singl
    {
       public static Singl instance = new Singl();
       private Singl() {}
       public void doit() { ... }
    }

    class EJBImpl
    {
       public void doit() { Singl.instance.doit(); }
    }

    There is also many talks about singletons in the Patterns section of TheServerSide.
  3. Singleton via deployment descriptor ?[ Go to top ]

    Thank you for the argument "programmer's/deployer's choice".

    I do not want to use a "real" singleton, because this may exist more than once on the EJB server due to the fact, that an EJB server can use several JVM's to do its job.
  4. Singleton in J2EE[ Go to top ]

    I also use singletons, but usually it's because i know the code is able to handle many threads, so the point of singleton sometimes is "only one instance is ok and most memory-friendly", so in that scenario, "one instance per vm" is also ok. Btw it is even possible to have 2 instances of one static variable in the same vm! So the singleton thing above is not 100% sure a singleton, even not when you're sure there is only one vm (it has something to do with class loaders).

    Can you tell me why it is essential to have one and only one instance of the object? And what is SLSB?
  5. Singleton in J2EE[ Go to top ]

    in our project we need a real singleton for the storage of request contexts. an asynchronous response (JMS) has to be associated with its request context to continue the workflow. an entity bean would work as singleton, but performance ...

    with SLSB I meant stateless session bean
  6. Barbara,[ Go to top ]

    Barbara,

    Option number one, why don't you use SFSB as a singleton? SLSB has a very limited lifetime, the container can choose to destroy the bean after any method call. That's what statefuls are for.

    Just synchronize calls to its methods and you'll get what you want. SFSB can be also easily replicated over your cluster.

    Another option is to serialize information to JNDI and if you locate JNDI server on the same machine, you will NOT loose a ton of time for that as people usually think, however, there is still a chance that it will be slower that you expected, however, you should keep experimenting. Most of the modern containers allow you to replicate the JNDI tree over cluster easy.

    The third option and the most advanced one is to purchase a third party product that will allow you to keep your data for long time ranges safe and up-to-date somewhere in a memory location within your application server environment. It can also distribute this data quickly between different nodes of your cluster or cell. You can take a look at a Coherence from Tangosol for that (www.tangosol.com). However, it could cost you some money.

    The fourth option could be to develop a JCA adapter for in-memory management. Your JCA can talk to Java or even C++ application via sockets and provide fast storage and retrieval of the customized data. If you develop light protocol that will be customized to your application requirements, you'll possibly get the most scalable, flexible and agile solution because it will have unlimited optimization possibilities. People usually stay away from the similar solutions and prefer to pay money for commercially available products, but it is almost axiomatic that customized products are usually better that universal ones, but they cost more. But think of your future projects, may be this kind of investment could be considered as a long-term bond with high yields in the future? You never know...

    Hope this helps.

    Alex
  7. Singleton via deployment descriptor ?[ Go to top ]

    Alex,

    thanks a lot for your very helpful information, I will follow it up.

    note to destruction of SLSB:
    in the EJB Spec I only found, that a container can terminate a session bean's (SLSB or SFSB) lifetime under certain conditions: after deployer-specific timeout or in case of failure.
    Otherwise the session bean is put back to the pool, and this would not affect the data stored in a member variable, would it ?

    Barbara
  8. Reply[ Go to top ]

    Barbara,

    Actually, putting SLSB in pool means the destruction of its context-related information (in reality, you get the same instance but bound to the different session context). From the client's point of view (not taking pooling issues into account) that means the same as the destruction of SLSB itself.

    Alex
  9. Follow-on[ Go to top ]

    Barbara,

    I've re-read the original message and finally got what you meant. If you're manually limiting number of instances in pool to single instance, that could work on some containers and may would not work (the way you want it) on either container.

    You see, J2EE spec doesn't actually limit the container when to remove or create an instance (that's the point where you loose your singleton data).

    Probably, you mixed it up a bit (or may be it's my mistake, correct me if I am wrong), but the cases you've mentioned are referred to "missed ejbRemove" calls (it's chapter 7.6.3 in the EJB 2.0 release spec) what is a different issue from what we're discussing.

    Moreover, you will still need a way to store the reference to the remote interface of your bean somewhere between session interactions. You can't reference EJB bean's remote interface by class name like you do with singletons (or you should have a singleton that returns your EJB's remote interface referance - kind of chicken and egg situation, isn't it?). You can sort it out with a reference to your remote in a session variable at presentation tier. However, you'll have to pass over this reference to your business logic tier everytime you want to work with your "singleton". That will add more troubles. You can also store this reference in JNDI, but in that case, I'd prefer storing the whole singleton object in JNDI (which will be much safer approach, you can't rely on your container - see above).

    Hope it helps.

    Alex
  10. Follow-on[ Go to top ]

    Alex,

    I also doubted, if the thing is J2EE conform.
    Based on the discussion with you, I won't use it.

    just to answer your points:

    concerning the termination of a SB's life cycle, I agree
    to you, that the EJB 2.0 spec is not precise.
    I read in chapter 7.1 :
    "... Its lifetime is controlled by the client.
    A container may also terminate a session bean instance’s life after a deployer-specified timeout
    or as a result of the failure of the server on which the bean instance is running."

    concerning the reference to the singleton:
    because the container is forced to have exactly one instance, an ejbCreate would always return the same instance. So no reference storage would be necessary.

    Thanks again.
    Barbara