On 2/10/07, Mon Cab <[EMAIL PROTECTED]> wrote:
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
