Ready for another theory?  Hold onto your hats for this one... If you're
using Apache Tomcat v5.X, you might try something like this:

The Tomcat context files allow a context to specify a session persistence
manager.  I think the default would be listed like so (from some Tomcat
examples):

<Manager className="org.apache.catalina.session.PersistentManager"
              debug="0"
              saveOnRestart="true"
              maxActiveSessions="-1"
              minIdleSwap="-1"
              maxIdleSwap="-1"
              maxIdleBackup="-1">
                <Store className="org.apache.catalina.session.FileStore"/>
          </Manager>

The theory is to override the PersistentManager with your own class.
Theirs subclasses the PersistentManagerBase which subclasses ManagerBase.
Now inside ManagerBase it seems to create the sessions in the method
createSession(String). If you override that, you could count the sessions
and if you already have one active, toss "IllegalStateException" to prevent
a second session from being created.  Just remember to reduce your session
timeout or make it clear a person must logout (so you can invalidate their
session) so the next person can get into the application.

So, how's THAT for a wild theory for you?

P.S. You can skim the ManagerBase.java code over the web at (sorry but this
will probably wrap and have to be cut/pasted to work)
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share
/org/apache/catalina/session/ManagerBase.java?rev=1.43&view=markup

I would think it wouldn't effect maxthreads or anything like that as long as
you make this webapp it's own context with the above (theoretical) session
limitation.

By the way, I tried setting maxActiveSessions="1" on a webapp the coming in
using both IE and FireFox. However, the Tomcat manager showed 2 sessions so
the simple assumption that maxActiveSessions would function as it's name
suggests is incorrect.  Again, it shouldn't be anything that can't be fixed
with a method override of some sort.

Regards,
David, the creative thinker tonight

-----Original Message-----
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 26, 2005 11:11 PM
To: Struts Users Mailing List
Subject: Re: probably a cleaner way... testing for just one user


David G. Friedman wrote the following on 7/26/2005 10:39 PM:
> John,
>
> Aren't those for simultaneous threads for the webapp, not to limit total
> sessions/session cookies?   I thought that just mean that the jobs get
queue
> up and run one at a time in that webapp, i.e. with fewer threads.  It
> wouldn't stop having multiple sessionIds for people at any given time.

Right that's what I thought as well. John, I don't want to create any
limit on the number of threads. I just wanted to limit the tool to just
one active session at a time (I know sounds crazy, but it's the way it
'gotta be' for this one).
--
Rick


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to