On Wed, Oct 20, 2010 at 12:41 PM, Denis Forveille <denis.forveille@gmail.com> wrote:
 The main difference between EJB 3.1 singleton and servlet listener is that the EJB 3.1 solution starts only one component in one
member of the cluster.. Not the latter.

I've seen questions about whether a singleton is in fact a unique member in a cluster. Since the Java EE spec doesn't specifically address clustering (right?), this requirement is open for loose interpretation. In fact, section 4.8 of the EJB 3.1 spec even suggests that this is not a guarantee:

A Singleton session bean is a session bean component that is instantiated once per application. In cases
where the container is distributed over many virtual machines, each application will have one bean
instance of the Singleton for each JVM.


So there is a difference between "application scope" and "application-as-deployed-in-cluster" scope.
Most of the so-called "ApplicationScope" components are not well named IMHO as there is one component per member in a cluster, not 1
per application as deployed in a cluster...

I would definitely agree with you there. The CDI tutorial in the Weld reference guide makes mention of a theoretical @ClusterScoped which would be a more apt choice.
 

We have a complex custom in-house solution for this with seam 2 and jEE5/WebSphere 7 (based on distributed map in WAS)  and we are
waiting for EJB3.1 and WAS v8 to have an elegant solution for this and we hope that seam 3 will have a solution also

And that's precisely the type of solution we want to provide in Seam 3 so that duplication of effort for such custom solutions can be avoided. We certainly welcome your review, feedback or contribution in tackling this scope.

Given that singleton session beans aren't likely unique in a cluster, then we really need to get serious about offering a cluster-scoped annotation. Pete, JIRA?

-Dan

--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen