In fact, the real need we have is to have "ClusterScope" components that has a
method annotated with "@Create" that "fires" only
once per application in the cluster.
For example to a post a -unique per application- message in a JMS queue or send a mail
saying "hey, the app is up", or do something
in teh database *once* or this kind of thing
I thought that EJB 3.1 solved the problem..
Today as application scope components runs in all member of the cluster, we have 1 message
in the JMS queue par cluster, and we have
to develop code to deal with that.
So the questions is: Will a method annotated with @Create (seam 2 notation here) in a
Singleton EJB fire only once for the cluster
or not?
Denis
On 10/20/2010 12:53 PM, Dan Allen wrote:
On Wed, Oct 20, 2010 at 12:41 PM, Denis Forveille
<denis.forveille(a)gmail.com <mailto: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