<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi,</div><div><br></div><div>Maybe I am stupid, but if you depend on your sessions to expire to release key resources, I think this always means you have a security hazard. One should not rely on what the user does or does not. So I think the question should be: why is it important to know the exact time the session expires? What data do you need to clear, that it cannot wait to be cleared?</div><div><br></div>Diego<br><div><div><br></div><div>On 25 Feb 2014, at 08:53, <a href="mailto:jtuchel@objektfabrik.de">jtuchel@objektfabrik.de</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      it seems this is a common request, because it pops up from time to
      time. Seems people are unhappy about the fact that the time
      sessions may exist after their expiry is undefined. So what
      Karsten describes is probably a feature request...<br>
      <br>
      For our application we decided to design our session classes to
      not hold on to critical resources for longer that they need them,
      so that their lingering after expiry is not an issue. For peace of
      mind, it would be nicer if sessions just got killed once they've
      expired.<br>
      <br>
      Joachim<br>
      <br>
      <br>
      Am 25.02.14 08:45, schrieb Karsten Kusche:<br>
    </div>
    <blockquote cite="mid:9F0EE891ABA240BEA9BC848ED8457FDD@heeg.de" type="cite">
      <div> i thought that’s not 10 created sessions but 10 queries to
        the cache. You can also create a background timer and let it
        access the application’s cache and trigger a reap. </div>
      <div><br>
      </div>
      <div>Kind Regards</div>
      <div>Karsten</div>
      <div><br>
      </div>
      <div>
        <div><br>
        </div>
        <div>--&nbsp;<br>
          Karsten Kusche - Dipl. Inf. -&nbsp;<a moz-do-not-send="true" href="mailto:karsten@heeg.de" style="color: rgb(0, 106,
            227); ">karsten@heeg.de</a><br>
          Georg Heeg eK - Köthen&nbsp;<br>
          Handelsregister: Amtsgericht Dortmund A 12812</div>
        <div><br>
        </div>
      </div><p style="color: #A0A0A8;">Am Dienstag, 25. Februar 2014 um 08:40
        schrieb Dave:</p>
      <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
        <span>
          <div>
            <div>
              <div>No hint?</div>
              <div><br>
              </div>
              <div>Dave</div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div>--</div>
              <div>View this message in context: <a moz-do-not-send="true" href="http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746106.html">http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746106.html</a></div>
              <div>Sent from the Seaside General mailing list archive at
                <a moz-do-not-send="true" href="http://nabble.com/">Nabble.com</a>.</div>
              <div>_______________________________________________</div>
              <div>seaside mailing list</div>
              <div><a moz-do-not-send="true" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a></div>
              <div><a moz-do-not-send="true" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a></div>
            </div>
          </div>
        </span> </blockquote>
      <div> <br></div></blockquote></div></blockquote><div>On 24 Feb 2014, at 11:39, Dave &lt;<a href="mailto:lasmiste@gmail.com">lasmiste@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br>I need to clear some data on session expiration. After several searches and<br>attempts I discovered that sessions expired after #cacheTimeout but they are<br>unregistered only after the creation of 10 more sessions, see here:<br><a href="http://lists.squeakfoundation.org/pipermail/seaside/2010-June/023663.html">http://lists.squeakfoundation.org/pipermail/seaside/2010-June/023663.html</a><br>and<br>http://lists.squeakfoundation.org/pipermail/seaside/2010-June/023670.html<br>you can change it reducing the cacheReapInterval, for example if you want to<br>unregister your session after 2 sessions are created, you can write:<br>myApplication cache reapingStrategy configuration at:#cacheReapInterval put:<br>2.<br><br>and you can test it creating a MySession:<br>MySession&gt;&gt;unregistered<br>super unregistered.<br>Time now inspect.<br><br>then associate it to your application:<br>myApplication preferenceAt: #sessionClass put: MySession.<br><br>and looking at the time of inspection, so far so good.<br><br>But...<br><br>I need to clean my data when the session expires (with or without a<br>timeout), not when the session expires *and* after 2 or more sessions are<br>created.<br><br>Have you any suggestion?<br><br>TIA<br>Dave</blockquote></div><br></body></html>