I have feeling the response will be 'that is really not a good idea', but I'm still asking. Also bear in mind I have had only a limited amount of exposure of WL clusters (I'm learning on the job so to speak).
We have an application in 2 Weblogic Clusters (these clusters are not aware of each other as in one domain) and each cluster as a queue that uses the same JNDI name and both are using JDBC to store messages - so they are using the same tables in the database. We are seeing problems in which problems in one cluster can cause problems in the other cluster (when we stop/start the app/service).
Does the above scenario sound like a recipe for disaster? One problem is that this queue name cannot be different in each cluster so I am thinking that if the above is not good then I should look at:
1. Switching from using JDBC to using a file store.
2. Creating some kind of JMS server for which both clusters point to.
I apologise for lack of clarity or wrong terminology, but I am just getting my head around WL clusters and JMS.
I'd suggest that within domains you use seperate JNDI name for every JMS object, in fact there is something about uniqueness with domains within the WLS documentation. You cannot target a JMS Server to more than one server. You can use Uniform Distributed Destinations and target these to multiple JMS Servers, but these are NOT supported over multiple clusters. Each cluster needs to have it's own set of JMS Servers in a cluster, using their own subdeployment for targetting and their own UDD.
I assume from your references about "using JDBC to store messages" you are using JDBC stores for the JMS Servers. Whilst you can use the same DB, setup up seperate schemas for every JDBC store, it will cause issues otherwise, or as you suggest, use a file store for each JMS Server.
Good question: Yes, definitely not a good idea - the two domains will corrupt each-other. Stores enforce exclusive access to their tables via a locking record mechanism, but you should not depend on this enforcement. The second domain's store will in theory fail to boot as it should detect that the table is already in use, but will succeed once the first domain shuts down - leading to unpredictable behavior.
I agree with Erasmus about naming - two domains must be named differently if they share resources such as the same file directory or database schema, if the same client communicates with both, or if they communicate with each-other. In addition, WL server names should be named differently even if they are in two different domains.