1 of 1 people found this helpful
The cluster nodes should use the same database (for application), otherwise you will have some funny results.
=> calls are spread over the cluster but each node contain other data, e.g. you create a person one node1 and try to get it on node2 (in this database nothing will be known about)
So you will have very fuzzy effects
Ok, JBossMessaging must use the same DB, the messages are handled with the PostOfficeId of each node for distribution and failover.
One special thing will be the timer service. If you share the same database the timer might fired on each node.
To avoid this you have to configure the TableName of the ejb-timer different for each node.
And for me the timer is the only one (except the application) that use the DefaultDS, but I removed some services.
A simple way to check is to remove the default-ds.xml and check the errors during startup.
Thanks for your help.
Our application already has it's own datasource pointing to a shared external db.
So, in conclusion, I can use a shared database for the remaining services that depend on defaultDS, but I'll have to tweak the timer service to use a different table name on each node. From a performance and reliability point of view, might I be better off keeping the defaultDS local?
I don't know exactly.
But in the past the HSQLDB make sometime trouble and error messages. So I decide to remove it also in test environment because it will be easier to check the database during runtime.
And because of this I don't know about the performance of HSQLDB.
But do you use the timer excessive? If not the problem will be theoretical
I was actually thinking about using local mysql databases. localhost mysql for the defaultDS, but the application and JBoss messaging each having their own datasource using external DBs.
Right Alex, you want to share your database with all JBoss instances so that messaging can use clustered queue and get all failover (HA) and load-balancing features. Otherwise your messages would have to be received only from that one node where they were sent. What do you actually want to keep in your local HSQLDB?
I'm not sure, but I think the overhead of an extra database per node is not necessary because you will not win a lot of performance benefit.