Singleton in a cluster

[Roberto Milev]

For part 2. My application is deployed on a cluster, and I have an SLSB for which I only want a single instance to run. I know JEE5 does not support this, but all Jboss, WebSphere and WebLogic have some sort of service that allows you to do it. Is it ok to just note this in my deployment diagram, or is this sort of design not allowed?

What are your thoughts/experience?

[Jeanne Boyarsky]

I would shy away from a proprietary feature on a JEE exam.

[assert assertion]

Shall we bind the singleton object to a JNDI ?

[Roberto Milev]

Thanks for you replies.

About binding the singleton to JNDI, I am not sure how that would work in this case? I have a SLSB using timer service to execute at regular intervals. This timer is initialized by a servlet context listener. I think the cluster will take care that the semantics for the EJB is the same when deployed in a cluster or single server. The problem is more about initiating the timer because in a cluster multiple servlet context listeners will execute for each node. Googling about this seems to indicate that the behaviour is JEE server implementation specific and in most case will result in multiple timers being created.

[assert assertion]

Can you please give some more detail about how your application is organized ? We can have the singleton SLSB EJB deployed as a seperate services EAR, and all the clusters (Schedulars) can point to the same EJB passing in the same JNDI url ?

[Roberto Milev]

The singleton SLSB EJB will be deployed in an EAR. This EAR will also contain a WAR containing a servlet context listener that initializes the timer on the SLSB EJB. How I see it, the problem is that in a cluster environment the servlet context listener will execute once for each node which will initialize the timer on the SLSB EJB multiple times (even if the SLSB EJB is a sigleton instance accesed via the same JNDI URL).

[Vijaykumar Dixit]

Hi Roberto,

By opening this topic, you actually reminded me of the same issue I have left unaddressed in my solution which I have already submitted unfortunately.

I am using a TimerService and a Timeout method on a SLSB which is going to be deployed in a cluster. At the back end side it obtains some data from DB and saves some data back after executing business logic. Optimistic locking on JPA side will avaoid any data issues cropping up but I think I should have written a line or two in assumptions about this.

[Roberto Milev]

Hi Vijaykumar,

That is exactly the solution I have right now. It would handle the case of multiple running instances using the DB transaction isolation as a synchronization mechanism. Although having a single instance would be so much nicer and save for a lot of unnecessary locking. Hope it is good enough.

Btw, did you pass, or still waiting on results?

[Vijaykumar Dixit]

Yes. I am waiting for my results.

Having a singleton instance is as good as suppressing the need for clustering for Timer based business logic execution, especially if all the cluster member share the same database.

There are many ways to tackle this issue based on the business requirements. For example if a scheduled job is billing the customers everyday whose bill is due on that day, the timed SLSB can be configured to process only a set of customers. Hence divide the workload (Customers by region,tariff etc.) amongst cluster members. In this case clustering would complement the improved performance.

But at the same time if you have lots of timer based stuff, then clustering may not be a good idea at all unless each member uses its own database.

All in all I would say, take an approach that suits well to your business requirements.