Erik, It appears that you want to incorporate two exclusive use cases with the same target domain (session management) into an application. If you want to preserve their exclusivity, I would recommend using different session management schemes for each of these cases. Doing so in the *same* application will be tricky. However, if what you are really looking for is a way to get out of these situations, read on. First and foremost, decide on which use case your application is going to support. In my experience, sharing a session is a much bigger sin than having each instance use (or appear to use, see below) a separate session. "Windows sharing a session should really be separate sessions" (Case 2) can be solved by repostulating the context. Problem: two browser windows share a session. (So what?) Real problem: if two windows share a session, requests coming from either window will cause collision at the session level (putValue()/getValue() will lead to unexpected results). Solution A: use URL rewriting as opposed to cookies. This may not work for all browsers. Solution B: allow session sharing (state management method [URL rewriting or cookies] is irrelevant) but store a Dictionary (Map, Hashtable, whatever) of objects based on a unique ID generated by the application (database sequence, java.rmi.server.UID, etc) and passed around as a parameter. See http://archives.java.sun.com/cgi-bin/wa?A2=ind9905&L=servlet-interest&O=A&P=168655 . (Note: the article describes Solution B; it has not been extensively tested). You will have to use a wrapper around HttpSession so that instead of calling HttpSession.getSession(), you'd call YourWrapper.getSession(). "Each window is a separate session" (Case 1) can be solved by repostulating the context :> Problem: each browser window causes a separate session to be created. (So what?) Real problem: objects stored in N separate sessions (from N windows) need to know about each other. (So what?) Really real problem: objects stored in N separate sessions need to know about each other, because they're part of the same logical transaction. Solution C: use a variation on a theme of Solution B above. This time, a logical transaction will have a unique ID that needs to be passed around as a parameter and all sessions that are part of the same transactions will know just that. All is well if you're using 2.0-compliant servlet engine. Then, you can store session IDs of sessions that are part of the same transaction and subsequently retrieve your data from these sessions by using getSession(String sessionId) method. No such luck exists in 2.1 or 2.2 spec. However, 2.2 spec says that multiple browser windows should yield the same session. (I hope all browsers/servlet engines/users configuring the browsers will be prompt to comply, hehe). Solution D: specific to the application domain. If you can persist relevant data while in the "intermediate" stage of transaction, it may be possible to use domain-specific logic for putting the pieces together using the persistent store as a single point of access. The schema used to persist your objects should contain a provision for grouping the data (on the transaction or other basis). Regards, Alex. Erik Hanson <[EMAIL PROTECTED]> wrote: > >This is addressed to people who have written real, non-trivial applications >using sessions: how have you handled users who open multiple windows >(instances of the browser)? > >There are two ways the session mechanism handles multiple, and different >browsers cause them to happen under different circumstances: > >1. Each window is a separate session >2. Both windows share a session _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
