I can't see why you should need to cluster the other stateless session beans but remember that if the entitiy beans are not in synch over the cluster they can contain different values on the nodes. So you probably want to cluster the entities! You may also want to cluster the JMS queues!
Thanks Welen! by "entitiy beans are not in synch over the cluster"; you mean that each entity bean should have a replica on every server node so that If a transaction is in the middle and the one node fails then the same request on failing node will be routed to the other active node which will complete/commit the uncomplete transaction?
As my application do not have any state so I was thinking if one node will fail then active request (s) on it will be terminated with some Internal system error and new coming request will go to other active node.
Just to be clear: What I mean with "state" is data in the HTTP session and Stateful Session beans.
I'm not talking about failover within a transaction. If you application is using entity beans you need to make sure that you are not caching the data (see "Commit Option") or using the clustered JBoss variant with the "cache invalidation" solution. Otherwise different nodes may have different values in the entities in memory.
Just to be sure: We are talking about EJB 2.1 not EJB 3?
1 of 1 people found this helpful
As Anders said, you should not cluster all local used beans.
To make it clear, create only local interfaces for all Beans that are only for internal use.
For the Entities it depends.
In most cases you have data changes within the entities, if so you should use an optimistic locking strategie without caching.
If you have some 'master data' that do not change very often you might use a caching strategie, but evaluate that this will have an effect for you!
Also it depends on the EJB version you use, within EJB3 it will be more simple, entities are always local without cache replication.
The entities without cache are only 'out of sync' during the transaction is running.
Yes I am using EJB 2.x and the entity beans I have uses Commit Options A, D and C. So I think I should cluster those having Commit Option A and D? regarding state, yes and I do not have any HTTP Session or StateFullSession bean.
Ok, what will happen in case of crash on Node A while a transaction was started but not committed, if entity beans are clustered then will the uncommited transaction on Node A will be continued and be commited on Node B?
There is no transaction failover. The transaction is not committed and the client can try again to call the service (manually or by the fail-over proxy in JBoss clustered RMI). The result of the "lost" transaction _can_ be regarded as rolled-back as the transaction manager hasn't decided on the outcome. (But it's a bit more complicated when using XA resources and Transaction Recovery though)
I clustered Entity beans but on server start up I see a warning for all clustered entity beans like below:
08:29:45,781 WARN [EntityContainer] *** EJB 'MyEntityBean' deployed as CLUSTERED but not a single clustered-invoker is bound to container ***
All my Entity Beans are local not remote.
I have set entity bean in jboss.xml as shown below; am I missing something?
<configuration-name>Standard CMP 2.x EntityBean Commit Option A</configuration-name>
Try to remove the "<configuration-name>Standard CMP 2.x EntityBean Commit Option A</configuration-name>". What you actually are doing here is to point out to JBoss to use a special setup (actually a non-clustered one)instead of the one that JBoss thinks suit your need best,