I'm looking at a new app, broadly speaking an IM application with a strong client-server model - all communications go through a server so they can be logged centrally.

The server will be Java in some form, clients could at this point be anything from a .NET Desktop app to Flex/Silverlight, to a simple web-interface using JS/AJAX.

I had anticipated doing the server using standard J2EE so I get a thread-safe, multi-user server for 'free'... to make things simple let's say using Servlets (but in practice SpringMVC would be likely).

This all seemed very neat but I'm concerned if the stateless nature of Servlets is the best approach. If my memory of servlets (been a year or two) is right, each time a client sent a HTTP request, typically a new message entered by the user, the servlet could not assume it had the user/chat in memory and might have to get it from the DB... regardless it has to look it up. Then it either has to use some PUSH system to inform other members of the chat, or cache that there are new messages, for other clients who poll the server using AJAX or similar - and when they poll it again has to lookup the chat, including new messages, and send the new data.

I'm wondering if a better system would be the server is running core Java, and implements a socket-based communication with clients. This allows much more immediate data transfer and is more flexible if say the IM client included some game you could play. But then you're writing a custom server and sockets don't sound very friendly to a browser-based client on current browsers.

Am I missing some big piece of the puzzle here, it kind of feels like I am? Perhaps a better way to ask the question would simply be "if the client was browser-based using HTML/JS and had to run on IE7+,FF2+ (i.e no HTML5), how would you implement the server?"

edit: if you are going to suggest using XMPP, I have been trying to get my head around this in another question, so please consider if that's a more appropriate place to discuss this specifically.