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

Reply via email to