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]