Network singletons


EJB design: Network singletons

  1. Network singletons (9 messages)


    Is there an EJB technique/pattern that caters for network singletons, i.e. a component that exists only in a single place in a server cluster?

    It would have to be a guaranteed "one and only one" situation, so that if the server running the instance faled, then another server would launch one, and so on.

    Threaded Messages (9)

  2. Network singletons[ Go to top ]

    How about a stateless bean with the max instances set to 1?
  3. Network singletons[ Go to top ]

    That depends on whether the EJB container recognised that parameter as being cluster-wide, not server-wide.
  4. Network singletons[ Go to top ]

    This isn't the end all solution but hopefully it gives you some ideas.

    I decided to implement an RMI server whose job was to maintain a single socket connection across a cluster. Each server in the cluster had one instance of the RMI server which concatenated its bind address to create a unique JNDI name. The RMI Server that obtained the socket connection became the "active server" and persisted its bind address in a database table. Clients used this database value to get the JNDI name of the active server. The benefits of this implementation was that it would run in any app server, the configuration for every server was the same, and it provided automatic failover. Hope it helps.

  5. Network singletons[ Go to top ]

    Interesting.... I'm not clear on who is connecting to what, though?
  6. Network singletons[ Go to top ]

    You are defeating the purpose of the cluster.
  7. Network singletons[ Go to top ]

  8. Network singletons[ Go to top ]

    I don't believe that I'm defeating the purpose of the cluster. I was forced to have only ONE cluster wide process (RMI server) maintain a socket connection to a remote server outside of the cluster. My implementation allowed me to support this with failover. The RMI server exists as a singleton on each server. Each RMI server repeatedly attempts to connect to the socket (the socket only accepts one connection at a time) and declare itself the "active server". If the "active server's" server crashes, another RMI server in the cluster will then grab the socket connection and declare itself the "active server" by updating the database record with its bind address.
  9. Network singletons[ Go to top ]

    Hi Daniel,

    If you bind the name of the server to the database and all clients would only connect to that particular server, then your server host would become overloaded and there's no load-balancing, only failover.

    I encountered the same problem too and implemented a cluster-wide singleton using simply an RDBMS as a cluster-wide storage for my Serializable objects. This way, I have load-balancing and failover. These objects are the results of some expensive computations and thus the time for JDBC calls to retrieve/persist the objects became quite insignificant. Depending on your mileage, this might be ok for your particular application, like it is for me.

    If that is too slow for you, I urge you to check out this open-source project called JavaGroups ( There's an implementation of a cluster-wide Hashtable (DistributedHash) that might solve your need.
  10. Network singletons[ Go to top ]

    Thank you Benedict. I was just trying to throw out some ideas using my real life experiences. From what I understand I don't believe your solution would have applied to my case. I had to maintain the sole socket connection to a server outside of the cluster. Failover was my concern, not load balancing. Only one process on the cluster could be "active" at any given time. If any of the processes obtained a connection, it declared itself the "primary" server and turned on its queue listener (each per-node process listened to the same queue). The other processes within the cluster became "secondary", kept their queue listeners quiet, and became relatively inactive (Except for their repeated tries to connect to the socket). The cycle repeats itself whenever the socket connection is dropped or a "primary" server died