I've added some notes about our clustering direction for Resin 4.0 at http://blog.caucho.com/?p=120
The main capabilities that we want for 4.0 clustering are: 1. dynamic servers (for load matching, and power savings) 2. simplify the administration model The main complexity of the current distributed session is that every server acts as a primary and a backup for some data. So it's difficult or impossible for an administrator to know exactly what happens when a server goes down due to maintenance or a crash. The new "triad" hub and spoke model simplifies that administration question. All replication occurs on the triad hub servers. So it's always safe to take down servers 4-64 at any time. The 3 hub servers (servers 1-3) are critical, but administrators can take more care with them because it's only 3 servers, and they're known as being more important. Those two requirements sound relatively simple, but imply a good deal of underlying infrastructure work. For example, distributed sessions since we no longer have the concept of an "owning" server, which means I need to add a temporary leasing concept that gives the same performance gains. For users, the changes should be mostly invisible. The first 3 servers in a cluster automatically form the triad, and all the replication and session caching happens under the covers using the current API. Single and dual servers work just like today. In other words, we're not adding a minimum requirement of 3 servers. -- Scott _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest