Custom HttpSession implementations

[croco]

... another reason is that by having no state in the web tier, it will scale horizontally with no bottlenecks, whereas I believe you would loose some of the possible gains of scaling that way if you have clustered session information.

I think that replication of the HTTP session actually brings you failover capabilities. As you said, for scalability, the session replicatication adds a drawback in performance (smaller for memory based replication, greater for DB based replication). If you are woried that some sensitive info might be lost in case of web server failure you should probably save it in the database anyway.
If you want just scalability you should use sticky HTTP sessions where all requets in a session are served by just one server instance. In this case, maintainng some state on the HTTP session it might actually help from a performance point of view, because avoids web server - (ejb server (- db server)) roundtrips.

[maward]

In this case, maintainng some state on the HTTP session it might actually help from a performance point of view, because avoids web server - (ejb server (- db server)) roundtrips.

I guess you are saying that if, for example, a user is working their way through a six page wizard, then by storing the information being populated by the wizard in the web tier you will not need to keep going back to the middleware server for each wizard page. That's an interesting point. I think I am now convinced that if we can use Tomcat-based sessions in conjunction with our middleware security then life would be much easier and would give a boost in certain areas such as automatic URL rewriting and Spring wizard usage.

Thanks for all your contributions!
Matt

[pmbh]

Hi,

I know this is an old thread, but I looking for a solution to a very similar problem and I've just found this. I've been looking for this kind of issue for ages but I've never find anyone asking something like this.

I'm starting to use Spring 2.5 in a new project, and now prepared to full coding after a hard, fast, fulltime and self-taughting course (reading a lot of documentation about spring, and testing some example stuff).

I was really happy when I saw the title of this thread, because I thought that Spring even bring me a solution to that, but I've seen it doesn't

The problem:
My applications are full based in HTTPSession, just because it's easy to base the conversation state, authorization info, etc in HTTPSession. And also about additional Session support in Web Servers, like session replication, persistence session, in files, databases, session expiration, etc.

But this is my real problem: HTTPSession is based either in a well defined cookie, like JSessionID or in URL codification of the same ID.

And?

My clients ask me for a simple HTTP API (similar to REST APIs). But there is a very strict requirement: not to use neither cookies nor url coding. They don't use Web Browser clients.

And I have to authenticate users, then I reply with an auth-token in an XML response. And they have to send me this auth-token as a well defined HTTP Param or HTTP Header. Yes, I know, this is like an invented cookie mechanism.

But they don't want another thing.

Now, I'd like not to change anything in my application, just using a filter that check for this token and associate it with the HTTPSession mechanism.

But.... Is it impossible to do it?. Remember that HTTPSesion is a full mechanism that I don't want to reinvent, like session expiration based in web.xml time configuration, etc...

I think the only solution it is to use internal Web Application Server library and override parts of its HTTPSession implementation, or to implement my own HTTPSession and then doing all that HTTPSession does.

But I'm surprised not to find any with a similar issue. Is it a too weird requirement? Am I looking for a very weird solution? Is it the solution so simple than I don't see it? Am I too silly?

Thanks
Pedro