> > > > The thing is, we don't really care what the topology is. The only > > requirement is that the session gets immediately deserialized once it > > is replicated to other node, which should be either default or at > > least configurable on most containers. > > > > So we let the container manage the replication topology. All we need > > is to be notified when the session is replicated (pagemap > > serialization and deserialization). All other approaches would require > > container specific code. > > Yeah.. well. when node A fails over to node B and user clicks the back > button is the end goal to handle that gracefully. I was just suggesting > a trivial way to accomplish the replication of the DiskPageStore's > actual files. This works around app container specifics for this point. > > Also you realize you responded to your own question asking about > topology..
I do :), but you don't seem to quite realize the importance of knowing the topology. First of all, one DiskPageStore location was never supposed to be shared across nodes and it will never work correctly that way. Each node must have separate location where it's DiskPageStore stores the files. Otherwise the result is pretty much unpredicable. This basically rules out usage of replicated file system. Unless you implement your own store probably with one file per page. We had such implementation, the problem was that the performance didn't scale well under load (lot of small writes). As for the topology. In order to scale well with growing number of nodes each node should be ideally backed by one other node. Applications servers do this. The advantage of current DiskPageStore implementation is that the DPS files are replicated to the exact node that backs the session. So they are not just replicated all over the cluster, which certainly wouldn't scale well. -Matej > > > ./C > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Resizable and reorderable grid components. http://www.inmethod.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
