Here is Rick's original requirement, > I have an odd requirement where this internal application should > only be used by one valid user(one session) at a time. (The data > being worked with in the application would require so many locks > that's it just easier to restrict it to one user).
Only if one session ends, another connection can establish connections, always you have only one user connect to data. It doen't matter if web-browser performing keep-alive or not. If web browser droped the connection, this session ends and original user drops connection. Another new (only one) session will begin. So still only one user connects. So this answered your posts below: >David said: it sounds like you understand the concept behind the > "acceptCount" but are relying on the browser to perform a keep-alive to hold > the connection open...If the keep-alive > doesn't work for a given browser, then the HTTP request is over in a second > and the next person can login to the site. Remember the first person does not connected when the second connected--still one user using data only. -------------------------------------------- > David said: Then, you would also have the issue of needing a Connector for that one > individual webapp and another connector, or other connectors for the > remaining webapps on that Tomcat server which would need to allow multiple > connections at one time (like regular web sites). Tomcats can have multiple connectors. I don't see a problem here. Again, I just try to see if configuration is possible for this interesting problem. I think Rick's coding OK also. Regards, John H. Xu ----- Original Message ----- From: "David G. Friedman" To: "Struts Users Mailing List" Subject: RE: probably a cleaner way... testing for just one user Date: Wed, 27 Jul 2005 00:19:12 -0400 > > John, > > From your notes below, it sounds like you understand the concept behind the > "acceptCount" but are relying on the browser to perform a keep-alive to hold > the connection open. I feel that is one dangerous assumption that the > keep-alive will work for his "main" user's browser. If the keep-alive > doesn't work for a given browser, then the HTTP request is over in a second > and the next person can login to the site. > > I would be interested in reading other opinions (Rick, especially) on http > keep-alives and how reliable they are in cases like that. > > Then, you would also have the issue of needing a Connector for that one > individual webapp and another connector, or other connectors for the > remaining webapps on that Tomcat server which would need to allow multiple > connections at one time (like regular web sites). > > Again, now Rick has theories and opinions on various other methods plus his > original Filter/sessionListeners approach. > > Regards, > David > > -----Original Message----- > From: John Henry Xu [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 26, 2005 11:52 PM > To: Struts Users Mailing List > Subject: RE: probably a cleaner way... testing for just one user > > Hi David, > > The problem was interesting. So even Rick made his mind I think it is > beneficial to see if configuration was possible for the requirement. > According to Rick: > > > I have an odd requirement where this internal application should > > only be used by one valid user(one session) at a time. (The data > > being worked with in the application would require so many locks > > that's it just easier to restrict it to one user). > > The server.xml in Tomcat 4.1.27 > > > port="80" minProcessors="1" maxProcessors="1" > enableLookups="true" redirectPort="443" > acceptCount="0" debug="0" connectionTimeout="5000" > useURIValidationHack="false" disableUploadTimeout="true" /> > > "acceptCount" is for how many connections would be queued, right? If one > user is using the connection, maxProcessors is 1, others automatically > can not connect. So this user will use data alone.By setting > acceptCount="0", no other connection will be queued also, right? Cookies > seems not in original requirement. If others cannot connect, there is no > other sessions. It is similar in Tomcat 5, although it uses maxThreads as > name. > > John H. Xu > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Jack H. Xu Technology columnist and editor http://www.usanalyst.com http://www.getusjobs.com (The largest free job portal in North America) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm