On 2/10/07, Mon Cab <futon33@(protected):
>
> I think its going to have to be solution 1. All Im really interested
> in is user data associated with a session, so I'll probably map userId
> to sessionID in the DB and then pull user info when the service sends
> me a session id.
>
> I like the idea of the session map though. Maybe use a singleton to
> store the map and then access the sessions from there. Why do you say
> this might not be a good idea?

We did exactly that for a similar reason and it worked out perfectly.
We even went further and replaced web-containers session by an own
session implementation with useful enhancements (auto-expiring
attributes, auto-distributed attributes and so on) and an own session
management and there were absolutely no drawbacks. We also associated
current session with the http-worker-thread giving us the ability to
access the session from anywhere inside the container without
explicitly passing it as parameters through dozen layers of code.

All in one having a central point where all sessions are stored is
definitely the way to go, and having access to the session outside of
the request scope gives you a lot of possibilities which you don't
have in standard environment. I think that its a serious flaw in the
spec, that you aren't able to access the session when you need it.

regards
Leon

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)