Tamas, Do you say that the first person who dropped connection still doing data access on data sources (and two person using data the same time)? Rick's original objective was trying to limit one person use data sources.
> >>Rick's 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). > >> John H. Xu ----- Original Message ----- From: "Tamas Szabo" To: "Struts Users Mailing List" Subject: Re: probably a cleaner way... testing for just one user Date: Wed, 27 Jul 2005 14:08:36 +0800 > > John Henry Xu wrote: > > > 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. > I'm not sure that I got this right: > > "If web browser droped the > connection, this session ends and original user drops connection." > > The session doesn't end when the browser closes a connection. > > If you limit the HTTP connections thath can be made to an > application to 1, it will not > assure you that you will have only 1 session at a time. > > If the browser closes a HTTP connection to the web server the > session of the user will still > be alive on the server. And if a second user opens a connection in > this time he will be able > to open a second connection and so on... > > Furthermore a browser can make more connections to a web server to > load data(for example > it loads images found in a HTML using separete connections). > You would block all this 'extra' connections if you used your approach. > > > > >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. > > > > > The first person is not connected but it has a Session on the server. > The second user can connect so he gets another Session. > > The original requierment said: > > I have an odd requirement where this internal application should > only be used by one valid user(one session) at a time. > > > It says *one session* explicitly. > > Tamas > > > > --------------------------------------------------------------------- > 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
