The bottom line here is that the browser had no way of knowing that a
new directory was created for the user when the session started, and
shouldn't be responsible for performing cleanup when the session ends.


I think you should look at a "Session Expiry Listener" available in one
of the DRK's I think.


If you pull the plug, no browser windows are closed programmatically.


Etc, etc etc.  Doing a session listener makes 100% of directories
created get destroyed whenver a session is destroyed.


Other than that, you can add some code to application.cfm


<cfif session.isloggedin-or-whatever>
    <cfif datediff('n',now(),session.laststamp) gt 5><cffile append
now() to the file in the users' folder><cfset
session.laststamp=now()></cfif>
</cfif>


Then cfschedule something to loop through all files which were last
modified 1 hour ago (or whatever your session expiry time is) and delete
the folders.


Just a thought, if you can't do the session listener....
-dov

  _____  

From: S.Isaac Dealey [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 22, 2004 10:14 AM
To: CF-Talk
Subject: RE: Kill window Kill session

> If  you have J2EE enabled you can create a
> HttpSessionListener
> implementation which clears the directory when it receives
> a
> sessiondestroy callback.  This will do your cleanup
> automatically and
> does not rely on client-side scripting which sometimes
> doesn't work:
> (Examples: computer shuts off/unplugged,

If it's actually shut off (as oposed to being unplugged) I believe the
OS typically closes the browser window as part of the shut-down
process... at least that's true of Windows -- I can't say for certain
about Unix operating systems, although I can say that if I used them I
think I'd want them to. For much the same reason I like encapsulating
"events" in my code -- there's always that "what if" involved in
terminating it without launching any events associated with it's
termination -- plugins that need to do something when the browser
closes, etc...

> User kills the app,

JS handles this.

> non standard browsers

JS can do a pretty good job of mitigating this.

Although you'r right, an HttpSessionListener event is liable to be
more bulletproof. It's also liable to make anyone who's not well
versed in Java lose their lunch, their hair and their marriage all at
once. :)

s. isaac dealey   954.927.5117

new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework
http://www.sys-con.com/story/?storyid=44477&DE=1
  _____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to