Gertjan
I recently came across this - very small no of users on an internal intranet with csp. typically they log on and stay on all day - 8 hour session timeout Buy exactly the license count that matches the number of users if all is OK - fine but if they closs cross the browser or crash or want to open another browser window they need a spare license in order to see the logon screen - so they can get logged on and then do the normall license trading upto 12 connections from the logged on user ==== I had a thought on this - maybe when I have time will play make the logon-screen a non-csp app (asp,perl whetever), the username/pasword is checked via a Cache Factory or ODBC stored procedure call if the password is OK then redirect to the Cache app - session starts at this point this also has the advantage that hackers cannot mount a DoS attack on the login screen cos it's non-Cache and consumes no licenses - and you have to have a valid logon to get into the csp app Peter On Tue, 17 Aug 2004 17:51:45 +0200, Gertjan Klein <[EMAIL PROTECTED]> wrote: >Bill McCormick wrote: > >>Because the background CSP process is not using a license - remember the >>license is held by the session, not the process - we take a license on >>the jobbed process by default. Then you can tie it to whatever you like >>through the available API's. > >This makes sense, but has the unfortunate side-effect that at least >one free license slot must exist to start a job from a CSP page, even >though this job shouldn't (and won't - after the login) take up a >license slot. > >Doing the login *before* the Job prevents this requirement for an >extra license slot, but presumably permanently ties the CSP process to >a license, which seems undesirable. I have not found a way to return >the CSP process to it's state of not using a license connection after >the Job. > >Do you know of a workaround that removes the requirement of a free >license slot without tying the CSP process to a license? > >Gertjan.
