Clustering with RMI classes

Answer 1

Prasad:
          I'm talking about a UserCache. It is not that much information, but it contains info
          from a lot of different tables. So if you came to our site and had a session then went
          away. Your session will expire at some point. Then when you come back, if we have a
          UserCache on the machine you were on, you are probably in there, but if you end up on
          another machine then we have to reload from the database. So what I'm thinking about is
          a static UserCache that resides on a machine that all the machines in the cluster could
          use.
          Thanks,
          Rob
          Prasad Peddada wrote:
          > Rob Williams wrote:
          >
          > > Jon:
          > >
          > > I was going to post a message about almost exactly the same thing. My thing is
          > > that I have a UserCache right now so that if someone comes back to the site we
          > > load their information up instantly. Obviously, if you come back to the site and
          > > get put on a different machine, we get your stuff from disk.
          >
          > Rob,
          > May I ask you what kind of information you want to load and how big is the
          > data?
          >
          > > We had a consultant come out who was sent by BEA to help us implement clustering
          > > and he recommended that we do in memory clustering by having a machine out front
          > > to 'proxy' and then a cluster. I asked a question on here and the BEA guy
          > > (Michael) seemed to think that that was not a good idea. Had it been a good
          > > idea, I was thinking the proxy machine (which I would have doubled w/another to
          > > avoid a single point of failure) would have been a good place to put the
          > > UserCache and then the machines in the cluster could just get the user info
          > > using RMI.
          >
          > I am trying to understand why you need RMI. When you use session replication
          > mechanism basically you have failover mechanism. If one server goes does the other
          > one still has all the information you need. Its too expensive at this point to
          > replicate the state information across all the servers in the cluster whether it is
          > RMI or EJB. Based on number of servers you have in the cluster, the session
          > replication failover mechanism might very well serve your needs.
          >
          > Prasad
          >
          > > Thoughts?,
          > >
          > > Rob
          > >
          > > Jon Eagles wrote:
          > >
          > > > All,
          > > >
          > > > I am in a situation where I want to create an RMI object which represents a
          > > > cache. For simplicity, let's say that the cache is called IntegerCache and
          > > > it holds a hastable of Integer objects as a private class variable. When my
          > > > Weblogic servers start up, I want to make use of the startup class
          > > > functionality to create an instance of the IntegerCache and populate it with
          > > > the Integer objects representing the numbers 1, 2 and 3. I then want to put
          > > > the IntegerCache object into the cluster-wide JNDI tree at the name
          > > > "cache.IntegerCache". It is my understanding that each server in the
          > > > cluster will create its own IntegerCache and add a stub to the service pool
          > > > stored at the node "cache.IntegerCache". Assuming that I have three servers
          > > > in my cluster, at this point, I have three IntegerCache stubs in the service
          > > > pool.
          > > >
          > > > Now, suppose a client wishes to get a reference to an IntegerCache out of
          > > > the tree and let's further assume that it gets the stub from server 1.
          > > > Since we are using RMI and the object does have state (the hashtable of
          > > > Integer objects), we must use the targeted model to retrieve a pinned
          > > > reference.
          > > >
          > > > Given the above scenario, can anyone tell me whether the following is
          > > > accurate:
          > > >
          > > > 1. If the client then adds Integer 4 to its IntegerCache stub, that Integer
          > > > will ONLY be added to the hashtable for the IntegerCache object that resides
          > > > in server 1. This addition will NOT be replicated to the other servers.
          > > >
          > > > 2. If statement1 above is correct, how can I achieve a solution where I
          > > > have a shared cluster-wide cache object. I don't want to have to implement
          > > > the individual cached objects (in this case Integers) as entity beans and
          > > > have the container constantly load and passivate them. The reason for this
          > > > is due to the fact that there is significant overhead involved in creating
          > > > my "Integer" objects and I would like to minimize the number of times I have
          > > > to do this.
          > > >
          > > > Any help would be appreciated.
          > > >
          > > > Thanks,
          > > >
          > > > -Jon