Hey James, 2009/4/7 James Bewley <[email protected]>: > Hi all, > > As there are huge demands on web services is pretty common and business > strive for 100% availability, I was wondering if WT has any specific > features for these environments. Clusters appear to be common in these > situations with the requests being load-balanced across several machines. > The main issue that arises when the system is state-full (as is the case > with witty) is sharing the current session state across multiple machines. > Of course witty can be used in these environments with persistent routing > via the load-balancing daemon. I was wondering if witty provides any > specific methods to facilitate sessions sharing?
So, yes indeed, you can easily use a load balancer with session affinity, and Wt's built-in http has also support for this to generate sessions that start with a given prefix. > Is there anything one should be wary of when using witty in a clustered > environment? One could compare to J2EE, where built-in "clustering support" means that session state is serialized and replicated to other application server instance(s) which can takeover when one application server goes down. Wt does not have this feature. Session state in Wt can also be fairly big (i.e. the entire widget tree, including application-data associated with custom widgets). However, in practical terms, even in J2EE land, it is common to not to use clustering-support of the application container to serialize the session state, but instead to commit the session state to a shared database at certain transactional points. The reason is that none of the clustering solutions guarantee 100% no data-loss unless they use synchronous communication between nodes, but that approach is not popular becomes it slows the application down a lot. The approach is only advised when session state is small (basically for almost stateless applications). So I think that the best approach for high availability with Wt is: - load balancer with session affinity - commit session state to a shared database at transaction points - use Wt's internal path API (pretty urls) for state related to the user's current activity, so that on failure, the application continues at the right place. Regards, koen ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
