Forgot: Mutable and @ReadOnly are two alternative ways to do the same thing: trigger replication of a Seam Component only when needed.
Also, I saw in the code that the distributable attribute adds the ManagedEntityInterceptor, which also facilitates replication.
Does this mean that I can deploy my application without any special cluster treatment (given that I don't need replication)?
deadlock gr wrote on Jan 19, 2011 17:31:
We have a Seam 2.2.1.CR1 application with JSF 1.2 on a Weblogic 10.3.2 (11g) cluster. The cluster does not have session replication, we just have a load balancer in front of the cluster, which balances the load between the cluster nodes. Although Seam does have documentation on clustering here, it is not very clear to me what I must do in my case.
The documentation says:
Any session- or conversation-scoped mutable JavaBean component that will be used in a clustered environment must implement the org.jboss.seam.core.Mutable interface from the Seam API. As part of the contract, the component must maintain a dirty flag that is reported and reset by the clearDirty() method. Seam calls this method to determine if it is necessary to replicate the component.
This tells me that implementing the Mutable interface has to do with session replication, which is something I don't want to support.
Also, another part of the documentation indicates that I should use
Do I? Or this also has to do with the replication?
And yet again, do I need to use the @ReadOnly annotation, because I believe that this, too, has to do with session replication.
Should I be using any of the above (Mutable, distributable
Click HELP for text formatting instructions. Then edit this text and check the preview.
All those are for session replication. Since pretty much everything in Seam 2 is in the session (including the SMPC and loaded entities), you need to have replication if you want failover, etc. In practice it doesn't work that great, but with a bit of work it's usable.
If you are not doing replication, what you have is not a cluster, just two separate instances of an application. You shouldn't need to worry about any of the above.