There was an article in the October issue of Dr.Dobbs Journal on issue relating to this one. It was actually about handling user requests that may have come in from different browser windows but try to do the same thing or handling requests that were stopped and then, after clicking 'Back' re-initiated. It uses the idea of marking each browser with a session ID but goes further even. It allows for certain 'flow' so if user has two browsers open and try to do the same transaction on both of them one of the windows will get a message that this transaction is taking place already for that particular user. Very interesting and with source code. dave. "Kirkdorffer, Daniel" wrote: > [apologies I accidentally sent the previous reponse prematurely - please > reference this one] > > > You sir are correct! > > > > However, what we do is we have user sessions that hang off the browser > > session. We can detect if a user is sending us a virgin request (i.e. one > > we haven't stamped with an ID yet), and create a new user session, that we > > store with the browser session, and then we send back the user id stamp > > with the page that is served up so that subsequent requests from that user > > session can be identified from others. > > > > In general, all of the apps we do this for require a login, which acts as > > a formal front door for this to happen, but as long as you have the code > > in place to check identity you can do this from any page, it just is a > > little extra work. > > > > Here is a little write up I did a while back explaining what we do. We > > actually have another layer between the user session and the browser > > session that I cann the web application object. The attached diagram trys > > to show the setup. > > > HTH, > > Dan > > -- > > Daniel Kirkdorffer > > NACN IS: 425-580-6225 > > Sr. Consultant, Syllogistics LLC > > Email: [EMAIL PROTECTED] > > Web: http://www.syllogistics.com/ > > > > > <<sessions.gif>> > Managing Distinct Application Instances > > A given browser can be identified by its session using the HttpSession > object. Therefore the same user, using different browsers (perhaps Netscape > and MS IE), can access the same web application, but data stored with the > session objects will not conflict, as each would be working with a different > session object. > > If, however, a person wished to create multiple instances of the same > browser (i.e. by opening multiple browser windows of that browser), and > access the same web application through each of these, we would have a > problem because they would all be sharing the same session object. > > In order to enable multiple disctinct instances of a web application, > accessed through the same browser, we need to ensure each application has > its own application space. To do this, we simply need to do two things: > > * Create an application object that will be used for storage instead, > and store this object with the browser's session object, and, > > * Ensure each application object is uniquely named. > > The diagram above illustrates this architecture. Within a given browser > session we will maintain application specific objects, that in turn contain > application instance objects (correspoding to a user login perhaps) within > which we store that application instance's (user's) data, database > connections, etc... The manner in which these are implemented will be > specific to the application, but the following guidelines apply to every > application: > > * The first servlet call (often the login servlet call) is responsible > for creating the application object (if one doesn't yet exist) and unique > application object instance. An acceptable convention to follow would be to > append a timestamp to the end of an application specific object name. An > application timestamp string could be used to uniquely identify the > application object. If the application object would normally be > "XYZAppSession", the unique application object could look something like > "XYZAppSession19990504104835729". > > * Each subsequent servlet call will need to correctly reference the > unique application object, by either providing the unique application object > name, or at the very least, the unique identifier/timestamp. In order to do > this the client web page will have to have access to this info. Therefore > at least one page displayed (this could be one frame in a frameset), must > have a "hidden" INPUT value containing the information, perhaps like so: > > <input type=hidden name=appTimestamp value="<%= appTimestamp %>"> > > * In the above example the appTimestamp is being set through a JSP > Bean of type String. This will require the page in question is a JSP page > so that it can receive the variable. Whenever a call to a servlet or JSP is > made this value needs to be a part of it. Other Web FORMs, possibly in > other frames will need to grab the value and fill their own hidden > "appTimestamp" field prior to a submit (this can be done though normal > cross-frame referencing). "Get" method calls will need to append the > appropriate parameter info to the end of the URL. The point of only > populating one of many frames is to eliminate the need to explicitly set > value references in each page, which could entail more work. One should > look for a frame that doesn't change very often, if at all, as the primary > holder of the identifying information. Only populating one of the frames > with the unique identifier, however, could yield code that is more difficult > to maintain, as too many cross references could create confusion. The web > developer should try to apply the appropriate approach that will both be > easiest to implement and easiest to maintain. > > * Each reference to the application object will use the information > passed in each request to access the unique application object correctly. > For example: > > AppSession jspexampleSession = > (NACNAppSession)browserSession.getValue("XYZAppSession"); > AppSession userSession = > (NACNUserAppSession)jspexampleSession.getValue("XYZAppSession" + > > req.getParameter("appTimestamp")); > > The above code uses the timestamp to uniquely identify the appropriate > application object instance within the application session space (which in > turn is stored within the browser session space). > > > ---------- > > From: Joel Reymont[SMTP:[EMAIL PROTECTED]] > > Reply To: Joel Reymont > > Sent: Tuesday, November 16, 1999 5:17 PM > > To: [EMAIL PROTECTED] > > Subject: Tracking sessions in browser windows > > > > How do you do this? I was under the impression > > that the cookie is set per browser app (IE, NN) > > and not per browser window. Am I mistaken? > > > > Thanks, Joel > > > > > -----Original Message----- > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Kirkdorffer, Daniel > > > Sent: Tuesday, November 16, 1999 12:59 PM > > > > > > Well, my application distinguishes user sessions so that a user can > > login > > > multiple times in separate browser windows. > > > > ========================================================================== > > = > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > > JSP-INTEREST". > > FAQs on JSP can be found at: > > http://java.sun.com/products/jsp/faq.html > > http://www.esperanto.org.nz/jsp/jspfaq.html > > > > ------------------------------------------------------------ > Name: sessions.gif > sessions.gif Type: GIF Image (image/gif) > Encoding: base64 -- David Mossakowski [EMAIL PROTECTED] Programmer 212.310.7275 Instinet Corporation "I don't sit idly by, I'm planning a big surprise" ___________________________________________________________________________ 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
