Brian, thanks for all of your help. I do have another question regarding on how we are setting up the 3 nodes.
I am using apache with mod_jk and want to setup the cluster as follows.
| Node1 Node2 Node3
| Active Standby Active
| Buddy node2 Buddy node2
|
and setup the load balancer to send traffic to either node1 or node3 and only send to node2 if 1 or 3 are down
I want to do this to reduce the amount of memory required for running this many instances.
>From my understanding the session state will only be replicated to node2 from either of the other active nodes unless node2 goes down.
Will this work? and is it worth while to do it this way??
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020729#4020729
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020729
Not quite. Things in the WAR can see everything, but nothing can see into the WAR. Other than that, everybody can see everybody else.
Everything in the lib, deploy, ear, sar are in the same class repository (thus they all have visibility to each other) by default, though you can configure an ear or sar to use a separate class repository (see the JBoss Messaging sar for an example) in which case things in that ear and sar are hidden in much the same way things in a war are hidden.
By the way, I created some simple classes that referenced each other and deployed them different locations to verify the above.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020717#4020717
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020717
This is expected behaviour. If you have concurrent threads changing the same node at the same time, one of the threads will fail.
In pessimistic locking, the 2 threads are NOT ALLOWED to change nodes at the same time and one thread waits. This leads to poor concurrency. Optimistic locking allows both threads to access nodes at the same time and hopes that one thread will just read and not write. If simultaneous writes happen, you will naturally get a concurrent modification exception.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020706#4020706
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020706