1 of 1 people found this helpful
In general, if you have a webapplication that uses the SFSB's and SLSB's, the calls are prefered local (nevertheless whether you use Remote or Local interfaces.
If you use Local interface it is clear that the call must be local.
So for a SLSB there is no need to be clustered if you have only this use-case.
But for a SFSB there is a need for @Clustered, the reason is that your webapp can be failover to the other node, the websession is replicated, but in your case the SFSB not and this is an inconsistent state.
But yes your application will work correctly until such failover happens.
so if I don't use @Clustered the state of SFSBs is not replicated even if they are seam components?
My expectation is that, since they are seam components with Conversation scope their state will be replicated during web session replication, is that false?
I don't know about seam.
But if it is a SFSB, the state is inside this bean and I think seam does not replicate this (maybe if you give all informations back, seam will include that in the web-session, but I don't think so the SFSB is overhead in that case).
The state of a SFSB is replicated by JBossCache or Infinispan (AS6 / AS7).
At least I would ask in a seam forum (don't know whether there is one) or maybe you will get an answer from a seam guy here.
A fast way is to start your test-cluster and kill the node where the SFSB is active you will see whether the state is replicated.