4 Replies Latest reply on Mar 21, 2004 1:40 PM by Ron Emrick

    Client Access of Master Singleton Node

    Ron Emrick Newbie

      I've deployed a singleton MBean (using the Singleton Service) in a clustered (2 node) environment. I'd like to have my clients always connect via the RMIAdaptor to the master singleton only. Is there a way to do this easily? Do the clients have to "listen" to who the master is and detect changes?

      It seems now in simple tests that my client (using HA-JNDI) does not discern which singleton MBean is the master. It uses the HA-JNDI to find the RMIAdapter and then it appears that whichever node I get connected to with the RMIAdapter is the singleton instance that gets invoked (I use a simple dummy method to see the results of which instance is called).

      Thanks,
      -Ron

        • 1. Re: Client Access of Master Singleton Node
          Scott Stark Master

          Yes, you will have to track this, or your singleton service can create a link to the RMIAdaptor under a unqiue JNDI name such that when a client looks this up through HA-JNDI, it finds the RMIAdaptor on the same node as the singleton.

          • 2. Re: Client Access of Master Singleton Node
            Ron Emrick Newbie

            Thanks Scott for the quick reply. I thought as much... I may be better served using the JBossCache.

            Just to be sure, the JBossCache is well suited for a clustered environment, correct?

            Thanks again,
            -Ron

            • 3. Re: Client Access of Master Singleton Node
              Scott Stark Master

              JBossCache supports clustering, although its not clear how this is an approriate replacement for a singleton.

              • 4. Re: Client Access of Master Singleton Node
                Ron Emrick Newbie

                I need a "centralized" cache and access to it. I was thinking of using a Singleton at first that could be accessed by all clients. The singleton would be the manager of the cache and would be the only entry point to read and write it. This isn't as simple as I thought for a myriad of reasons including the fact that all clients would need to "keep track" of which node was the master.

                Then I thought the DistributedState service would be a good way to go. This didn't pan out either for the simple fact that the DistributedState service isn't transactional.

                I'm now off investigating the JBossCache because, again, I would like to have a shared data cache that all clients can access easily and not have to worry about managing which node is the master as well as being able to have the state managed transactionally. From everything I know and have read so far, it appears the JBossCache is the answer. Sound right?

                In the end, what I need is a transactional cache (or gateway) for clients to access. The clients need to acquire a "global" lock from this cache (i.e. a counter is decremented), do some work and then release the lock (i.e. the counter is incremented). Simple algorithm, not as simple in a clustered environment where I'd like to take advantage of load-balancing and fault tolerance.

                Thanks,
                -Ron