On Wed, Oct 20, 2010 at 12:41 PM, Denis Forveille <denis.forveille(a)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