Storage/SAN vendors are pushing a lot of solutions in the "cluster shared resources" space and I'm seeing this crop up a lot more in enterprises with HA applications.
If one could find a solution that doesn't have driver issues and properly does atomic NIO locks, etc., in concept it would be very nice. Anything that worked thread-safely as filesystem-based resource storage on a single node would work fine in a cluster with a shared SAN FS. In practice, though, I haven't seen one of these work exactly as promised by the vendor yet. ----- Original Message ----- From: "Kyrre Kristiansen" <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, September 12, 2007 11:00:42 AM (GMT-0500) America/New_York Subject: Re: sessions debate (was Re: some benchmarking) Yes, you are right. You really have two options for this, 1. Use the database. This might not be a good solution for short-length, time-based session data. 2. Use some sort of cluster-sharing, eg memcached (which is C++, but I believe there's a Java-version for it as well), or other solutions. 3. Don't share sessions in the cluster, which means that you have to route the same client to the same server throughtout the session. This is usually done by cookies from the load-balancer (yet more cookies). There's a second way to make sure that the same requests come to the same server, but it's based on IP. Most large cooperations use NAT-style routing out, so that the load-balancer will only see one IP for up to thousands of users, which will give uneven load on the servers. Avoid this balancing scheme like the plague.
