--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/sAbPehQ8KCc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/79de44f8-7acb-4d31-807b-d0adc1ba9181%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com.
Expiration times can be set from 0, meaning "never expire", to 30 days. Any time higher than 30 days is interpreted as a unix timestamp date. If you want to expire an object on january 1st of next year, this is how you do that.
CREATE EVENT sessioncleanup
ON SCHEDULE EVERY 30 SECONDS
COMMENT 'Removes old session data'
DO
BEGIN
DELETE FROM tbl WHERE ....
END
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com.
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/sAbPehQ8KCc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com.
Yes that is still the case, problem is that there is nobody that could trigger that event and it is not ckear who to trigger. Let's say you use athe same datasource from 3 servers, if now a entry expires which of this 3 servers should be triggered and who is triggering this? Don't forget the sessions are no longer held in the memory of the server, so the server cannot know that now a session ends.
Micha
Am Montag, 16. März 2015 schrieb Pritesh Patel :
Hi All,--I know there were discussion where onSessionEnd doesn't call for cluster setup but it was mentioned that it will take care on 4.x (Railo) version.For one of my project using mysql datasource to store session variable and doing some operation onSessionEnd function but it never called? Just to confirm is onSessionEnd still not supported for database storage or am I missing something?Thanks,Pritesh
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
Come again? Are you telling me that when session storage is set to DB, then not only does Lucee palm of the storage of the session data to the DB, it also palms off the *management of the session* to the DB as well?
That seems... less than ideal.
Obviously fair enough for the storage to be handed off: that's the intent. However session storage & session management should not be conflated. Session management (and the full session lifecycle) should still be Lucee's remit.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/74BF5055-EDEB-427E-B785-8CA7ACC18842%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwibHy87Ya3apzRCCy-6VM_CHv7pVmrOLhx2Zk5B8%2BaOQ%40mail.gmail.com.
Obviously fair enough for the storage to be handed off: that's the intent. However session storage & session management should not be conflated. Session management (and the full session lifecycle) should still be Lucee's remit.Sorry I don't get your point here, maybe you should explain in more details what you mean
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/929230b9-08c0-4636-aa87-c4ba4916721c%40googlegroups.com.
We are talking only about one single thing, firing the "onSessionEnd" method when a session ends.
If we use an external storage to store the session, there are 2 ways to find out that a session ends.1. register yourself as a listener to that event with the external storage2. make pulls every x seconds to find out if a sessions have ended3. store the data external but keep the metadata still in memory (idletime,lifetime ...).What is the problem with this possible solutions:1. this would be of course by far the best solution, in my opinion the only clean solution.
3. this is the second best solution, this could work even with multiple servers, we just have an overhead with getting the initial metadata when you start a server.
of course having this solution and we have millions of session where every session only contains very little data, makes this solution useless.
On Thursday, 19 March 2015 09:23:06 UTC, Micha wrote:We are talking only about one single thing, firing the "onSessionEnd" method when a session ends.Well you might be. I'm not sure I'm only talking about that. But we'll get back to this once you clarify a few things...If we use an external storage to store the session, there are 2 ways to find out that a session ends.1. register yourself as a listener to that event with the external storage2. make pulls every x seconds to find out if a sessions have ended3. store the data external but keep the metadata still in memory (idletime,lifetime ...).What is the problem with this possible solutions:1. this would be of course by far the best solution, in my opinion the only clean solution.This is where we diverge.3. this is the second best solution, this could work even with multiple servers, we just have an overhead with getting the initial metadata when you start a server.Can you pls elaborate on this.
of course having this solution and we have millions of session where every session only contains very little data, makes this solution useless.And this.
Cheers.--Adam
--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/079b806e-da4c-4245-9639-95e0bcc803f5%40googlegroups.com.
between the linesMichaOn Fri, Mar 20, 2015 at 9:17 AM, Adam Cameron <dac...@gmail.com> wrote:
On Thursday, 19 March 2015 09:23:06 UTC, Micha wrote:We are talking only about one single thing, firing the "onSessionEnd" method when a session ends.Well you might be. I'm not sure I'm only talking about that. But we'll get back to this once you clarify a few things...If we use an external storage to store the session, there are 2 ways to find out that a session ends.1. register yourself as a listener to that event with the external storage2. make pulls every x seconds to find out if a sessions have ended3. store the data external but keep the metadata still in memory (idletime,lifetime ...).What is the problem with this possible solutions:1. this would be of course by far the best solution, in my opinion the only clean solution.This is where we diverge.3. this is the second best solution, this could work even with multiple servers, we just have an overhead with getting the initial metadata when you start a server.Can you pls elaborate on this.Let me explain like it works atm, after your request end Lucee is storing your session that is in memory down to the storage, but the session still remains in the memory, after some time the session was not used, lucee is removing that session from memory.So there is no longer as session in memory, only on the storage.So if we get a new request now, Lucee first checks if there is still a session in memory (with the cluster setting to false), only if not Lucee checks the storage for the session and loads the session from the storage.What we could change is that Lucee never removes the metadata of the session from the memory, only the session data itself, so Lucee is still aware that there is a session and it knows when the session will expire.So it is like valet parking...