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.
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?
JBossCache supports clustering, although its not clear how this is an approriate replacement for a singleton.
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.