On Sat, May 17, 2008 at 12:45 AM, Nathan Beyer <[EMAIL PROTECTED]> wrote: > By 'SessionContext', are you referring to the HttpSession?
It's not the HttpSession, because I am talking about a XMPP server here, not a HTTP server/servlet container, but it is a very similar approach. > Attributes in > session need to be managed carefully, as these attributes must be > serializable and distributable among a set of servers in the case of > load-balancing and failover. Scalability is an issue here. (I did not put many thoughts in this yet unfortunately, but...) Scalability in the XMPP world is a little bit different than HTTP, because XMPP works with durable TCP/IP connections while HTTP opens a short lived new connection on every request (I am not talking about Comet here). So if you loose your connection because of a server failure, you loose your session, have to reconnect, create a new session anyway. In a load balancing setup this might be different (proxy front server holding connections, servers in the back handling the session, back-end server fails, client doesn't notice). > In the case of single-server instances, this is > rarely noticed, but once you scale out to multiple servers you'll get some > interesting side-effects, depending on how a vendor implements the session > distribution. Well we are talking about a XMPP server implementation here. So luckily, we actually are the vendor ;-) > > In any case, the storage of a complex and large sounding object in the > session is probably best avoided. That's why I opt to not have it in the session. BTW, you would be surprised how many data some web frameworks store in session nowadays. But that's really off-topic. Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
