onSessionEnd doesn't call if using sessionstorage to database

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

How do you know your onSessionEnd is not being called. Crank your session
timeout down to a few seconds to test. Wrap your entire method body in a
try catch and log or E-mail yourself any errors. It’s possible it’s
running, but just erroring out.

Thanks!

~BradOn Monday, March 16, 2015 at 8:58:48 AM UTC-5, Pritesh Patel wrote:

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

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.

MichaAm 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
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

@MichaelO:

I’m not sure how the table looks like, but is there a expiration column
created and updated each request? The DB/Memory cluster doesn’t know what
the set session timeout is in the Lucee app. By adding the expiration
date/time it can be easier to add expiration on any type of cluster storage
by using that data field…

Enhancement request needed or am I explaining something that is already
there?

Mike2015-03-17 19:43 GMT+01:00 Michael van Leest <@Michael_van_Leest>:

In the case of MemCached, you can set key experation. But make sure you
remember this:

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.

In the case of MySQL, maybe some sort of scheduled event?

CREATE EVENT sessioncleanup

ON SCHEDULE EVERY 30 SECONDS
COMMENT ‘Removes old session data’
DO
BEGIN
DELETE FROM tbl WHERE …
END

Hope this helps…

2015-03-17 19:31 GMT+01:00 Michael Offner <@Michael_Offner>:

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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com?utm_medium=email&utm_source=footer
.
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Michael van Leest


Michael van Leest

Hi Brad,
Tried same thing. Put try catch and write fine in both block, it was called when session storage set to memory but not in case of dB.
BTW, I tried in Railo, not lucee. I will give try in Lucee as well.

Regards,
Pritesh> On 17-Mar-2015, at 8:40 pm, Brad Wood <@Brad_Wood> wrote:

How do you know your onSessionEnd is not being called. Crank your session timeout down to a few seconds to test. Wrap your entire method body in a try catch and log or E-mail yourself any errors. It’s possible it’s running, but just erroring out.

Thanks!

~Brad

On Monday, March 16, 2015 at 8:58:48 AM UTC-5, Pritesh Patel wrote:
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 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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@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.

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.

Am I missing something here? Entirely possible.–
Adam

On 18 March 2015 07:02:30 GMT+00:00, Michael Offner <@Michael_Offner> wrote:

Thanks for the translation from Swiss to US English :wink:
That is exactly the point!

Micha

Am Mittwoch, 18. März 2015 schrieb Brad Wood :

Michael L, I think you misunderstood the issue. It’s not that
there’s no
way to expire the data in the actual out-of-process storage, it’s
that WHEN
a session expires, how and where would Lucee be invoked to fire a
CFML
onSessionEnd method? A database server (MySQL, Couchbase, etc)
doesn’t
have hooks to run CFML based on internal DB events. The only way
would be
for the CF servers to keep track of the sessions themselves and keep
checking the out-of-process storage to see if it had expired. But,
that
would defeat the purpose of the out-of-process storage in the first
place,
right? Plus, which servers in your cluster would be responsible for
doing
that?

I understand what Micha is saying. At the point that you move the
session
storage and expiration out of the hands of the CF server, the CF
server
cannot respond to expiration events.

Thanks!

~Brad

ColdBox Platform Evangelist
*Ortus Solutions, Corp *

E-mail: brad@coldbox.org
<javascript:_e(%7B%7D,‘cvml’,‘brad@coldbox.org’);>
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

On Tue, Mar 17, 2015 at 1:46 PM, Michael van Leest <@Michael_van_Leest <javascript:_e(%7B%7D,‘cvml’,‘@Michael_van_Leest’);>> wrote:

@MichaelO:

I’m not sure how the table looks like, but is there a expiration
column
created and updated each request? The DB/Memory cluster doesn’t know
what
the set session timeout is in the Lucee app. By adding the
expiration
date/time it can be easier to add expiration on any type of cluster
storage
by using that data field…

Enhancement request needed or am I explaining something that is
already
there?

Mike

2015-03-17 19:43 GMT+01:00 Michael van Leest <@Michael_van_Leest
<javascript:_e(%7B%7D,‘cvml’,‘@Michael_van_Leest’);>>:

In the case of MemCached, you can set key experation. But make sure
you
remember this:

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.

In the case of MySQL, maybe some sort of scheduled event?

CREATE EVENT sessioncleanup

ON SCHEDULE EVERY 30 SECONDS
COMMENT ‘Removes old session data’
DO
BEGIN
DELETE FROM tbl WHERE …
END

Hope this helps…

2015-03-17 19:31 GMT+01:00 Michael Offner <@Michael_Offner
<javascript:_e(%7B%7D,‘cvml’,‘@Michael_Offner’);>>:

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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com

https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com?utm_medium=email&utm_source=footer

.
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+unsubscribe@googlegroups.com

<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.

To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com

https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com?utm_medium=email&utm_source=footer

.

For more options, visit https://groups.google.com/d/optout.


Michael van Leest


Michael van Leest


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+unsubscribe@googlegroups.com

<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.

To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com

https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com?utm_medium=email&utm_source=footer

.

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+unsubscribe@googlegroups.com

<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.

To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit

https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com

https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com?utm_medium=email&utm_source=footer

.
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEByzaDhGL2riPSc%3DPBz4id_r_2B3g-3E%3D2D7i%3Do1LB80yQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Sent from my Android device with K-9 Mail. Please excuse my brevity.

See my answers between the lines

Micha

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?

Lucee still holds a copy of the session in the memory, but this session
remains in the memory only for around a minute (depends on the amount of
sessions). Asynchronous it is also written to the storage (cache or
datasource), depending on the cache/DataSource used Lucee also has a
process that triggers a cleaning of the storage, when the storage itself
does not support this, this is only necessary for datasources but not for
caches.
This is a general process and not a individual one, so maybe a session is
removed that is expired for some time. So if a session expired in a cache
or a datasource lucee has no clue about it…

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.

Sorry I don’t get your point here, maybe you should explain in more details
what you meanAm Mittwoch, 18. März 2015 schrieb Adam Cameron :

Am I missing something here? Entirely possible.


Adam

On 18 March 2015 07:02:30 GMT+00:00, Michael Offner <@Michael_Offner <javascript:_e(%7B%7D,‘cvml’,‘@Michael_Offner’);>> wrote:

Thanks for the translation from Swiss to US English :wink:
That is exactly the point!

Micha

Am Mittwoch, 18. März 2015 schrieb Brad Wood :

Michael L, I think you misunderstood the issue. It’s not that there’s
no way to expire the data in the actual out-of-process storage, it’s that
WHEN a session expires, how and where would Lucee be invoked to fire a CFML
onSessionEnd method? A database server (MySQL, Couchbase, etc) doesn’t
have hooks to run CFML based on internal DB events. The only way would be
for the CF servers to keep track of the sessions themselves and keep
checking the out-of-process storage to see if it had expired. But, that
would defeat the purpose of the out-of-process storage in the first place,
right? Plus, which servers in your cluster would be responsible for doing
that?

I understand what Micha is saying. At the point that you move the
session storage and expiration out of the hands of the CF server, the CF
server cannot respond to expiration events.

Thanks!

~Brad

ColdBox Platform Evangelist
*Ortus Solutions, Corp *

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

On Tue, Mar 17, 2015 at 1:46 PM, Michael van Leest <@Michael_van_Leest> wrote:

@MichaelO:

I’m not sure how the table looks like, but is there a expiration column
created and updated each request? The DB/Memory cluster doesn’t know what
the set session timeout is in the Lucee app. By adding the expiration
date/time it can be easier to add expiration on any type of cluster storage
by using that data field…

Enhancement request needed or am I explaining something that is already
there?

Mike

2015-03-17 19:43 GMT+01:00 Michael van Leest <@Michael_van_Leest>:

In the case of MemCached, you can set key experation. But make sure
you remember this:

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.

In the case of MySQL, maybe some sort of scheduled event?

CREATE EVENT sessioncleanup

ON SCHEDULE EVERY 30 SECONDS
COMMENT ‘Removes old session data’
DO
BEGIN
DELETE FROM tbl WHERE …
END

Hope this helps…

2015-03-17 19:31 GMT+01:00 Michael Offner <@Michael_Offner>:

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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com?utm_medium=email&utm_source=footer
.
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Michael van Leest


Michael van Leest


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Sent from my Android device with K-9 Mail. Please excuse my brevity.


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
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/74BF5055-EDEB-427E-B785-8CA7ACC18842%40gmail.com
https://groups.google.com/d/msgid/lucee/74BF5055-EDEB-427E-B785-8CA7ACC18842%40gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Thanks Micha. I am not sure I understand concept correctly but how Lucee
able to delete records from database once expired (I think cleaning done on
every hour) in that case?
Particularly, for my this project case I can write trigger on
cf_session_data so it will grab expiration timestamp and put in into folder
that I want to since this is what I want to do on “onSessionEnd”.On Wednesday, 18 March 2015 00:01:15 UTC+5:30, Micha wrote:

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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Thanks for the translation from Swiss to US English :wink:
That is exactly the point!

MichaAm Mittwoch, 18. März 2015 schrieb Brad Wood :

Michael L, I think you misunderstood the issue. It’s not that there’s no
way to expire the data in the actual out-of-process storage, it’s that WHEN
a session expires, how and where would Lucee be invoked to fire a CFML
onSessionEnd method? A database server (MySQL, Couchbase, etc) doesn’t
have hooks to run CFML based on internal DB events. The only way would be
for the CF servers to keep track of the sessions themselves and keep
checking the out-of-process storage to see if it had expired. But, that
would defeat the purpose of the out-of-process storage in the first place,
right? Plus, which servers in your cluster would be responsible for doing
that?

I understand what Micha is saying. At the point that you move the session
storage and expiration out of the hands of the CF server, the CF server
cannot respond to expiration events.

Thanks!

~Brad

ColdBox Platform Evangelist
*Ortus Solutions, Corp *

E-mail: brad@coldbox.org
<javascript:_e(%7B%7D,‘cvml’,‘brad@coldbox.org’);>
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

On Tue, Mar 17, 2015 at 1:46 PM, Michael van Leest <@Michael_van_Leest <javascript:_e(%7B%7D,‘cvml’,‘@Michael_van_Leest’);>> wrote:

@MichaelO:

I’m not sure how the table looks like, but is there a expiration column
created and updated each request? The DB/Memory cluster doesn’t know what
the set session timeout is in the Lucee app. By adding the expiration
date/time it can be easier to add expiration on any type of cluster storage
by using that data field…

Enhancement request needed or am I explaining something that is already
there?

Mike

2015-03-17 19:43 GMT+01:00 Michael van Leest <@Michael_van_Leest
<javascript:_e(%7B%7D,‘cvml’,‘@Michael_van_Leest’);>>:

In the case of MemCached, you can set key experation. But make sure you
remember this:

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.

In the case of MySQL, maybe some sort of scheduled event?

CREATE EVENT sessioncleanup

ON SCHEDULE EVERY 30 SECONDS
COMMENT ‘Removes old session data’
DO
BEGIN
DELETE FROM tbl WHERE …
END

Hope this helps…

2015-03-17 19:31 GMT+01:00 Michael Offner <@Michael_Offner
<javascript:_e(%7B%7D,‘cvml’,‘@Michael_Offner’);>>:

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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com?utm_medium=email&utm_source=footer
.
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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Michael van Leest


Michael van Leest


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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

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 storage
  2. make pulls every x seconds to find out if a sessions have ended
  3. 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. Of course it should be possible that multiple Lucees could
    register for this events.
    Problem is this is not supported by the db/cache types we use, at least i’m
    not aware of…

  2. This is possible but a horrible overhead, in addition this only works
    when you not share the session storage with multiple servers.

  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.

MichaOn Thu, Mar 19, 2015 at 9:33 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Wednesday, 18 March 2015 12:00:26 UTC, Micha wrote:

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

Sorry… um…

There are two elements of a session which need to be considered:

  1. lifecycle management
  2. storage

These are separate considerations.

Lifecyle management is the whole “start a session” (this does whatever is
needed to create a session, and fires onSessionStart()), “track session
idle time”, “end a session” (this does whatever is necessary to end a
session, and fires onSessionEnd().

Storage is… where the session data go.

The lifecyle stuff is Lucee’s job. The storage might be Lucee’s job too,
or it might be seconded off to a cache or a DB or [some other
storage-brokering agent]. What the storage for the session data is is
immaterial to the session itself.

It sounds to me - and I hope I’m wrong here - that what you said is when
using some non-Lucee storage mechanism, you’re also offloading session
management to that mechanism too. This strikes me as being very dodgy
coupling, and a less-than-ideal conflation of two separate concerns.

Is that more clear?


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/929230b9-08c0-4636-aa87-c4ba4916721c%40googlegroups.com
https://groups.google.com/d/msgid/lucee/929230b9-08c0-4636-aa87-c4ba4916721c%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Got it… ThanksOn Wed, Mar 18, 2015 at 5:30 PM, Michael Offner <@Michael_Offner> wrote:

See my answers between the lines

Micha

Am Mittwoch, 18. März 2015 schrieb Adam Cameron :

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?

Lucee still holds a copy of the session in the memory, but this session
remains in the memory only for around a minute (depends on the amount of
sessions). Asynchronous it is also written to the storage (cache or
datasource), depending on the cache/DataSource used Lucee also has a
process that triggers a cleaning of the storage, when the storage itself
does not support this, this is only necessary for datasources but not for
caches.
This is a general process and not a individual one, so maybe a session is
removed that is expired for some time. So if a session expired in a cache
or a datasource lucee has no clue about it…

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.

Sorry I don’t get your point here, maybe you should explain in more
details what you mean

Am I missing something here? Entirely possible.


Adam

On 18 March 2015 07:02:30 GMT+00:00, Michael Offner <@Michael_Offner> wrote:

Thanks for the translation from Swiss to US English :wink:
That is exactly the point!

Micha

Am Mittwoch, 18. März 2015 schrieb Brad Wood :

Michael L, I think you misunderstood the issue. It’s not that there’s
no way to expire the data in the actual out-of-process storage, it’s that
WHEN a session expires, how and where would Lucee be invoked to fire a CFML
onSessionEnd method? A database server (MySQL, Couchbase, etc) doesn’t
have hooks to run CFML based on internal DB events. The only way would be
for the CF servers to keep track of the sessions themselves and keep
checking the out-of-process storage to see if it had expired. But, that
would defeat the purpose of the out-of-process storage in the first place,
right? Plus, which servers in your cluster would be responsible for doing
that?

I understand what Micha is saying. At the point that you move the
session storage and expiration out of the hands of the CF server, the CF
server cannot respond to expiration events.

Thanks!

~Brad

ColdBox Platform Evangelist
*Ortus Solutions, Corp *

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

On Tue, Mar 17, 2015 at 1:46 PM, Michael van Leest <@Michael_van_Leest wrote:

@MichaelO:

I’m not sure how the table looks like, but is there a expiration
column created and updated each request? The DB/Memory cluster doesn’t know
what the set session timeout is in the Lucee app. By adding the expiration
date/time it can be easier to add expiration on any type of cluster storage
by using that data field…

Enhancement request needed or am I explaining something that is
already there?

Mike

2015-03-17 19:43 GMT+01:00 Michael van Leest <@Michael_van_Leest>:

In the case of MemCached, you can set key experation. But make sure
you remember this:

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.

In the case of MySQL, maybe some sort of scheduled event?

CREATE EVENT sessioncleanup

ON SCHEDULE EVERY 30 SECONDS
COMMENT ‘Removes old session data’
DO
BEGIN
DELETE FROM tbl WHERE …
END

Hope this helps…

2015-03-17 19:31 GMT+01:00 Michael Offner <@Michael_Offner>:

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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com
https://groups.google.com/d/msgid/lucee/eb80d153-d2fe-4b7b-8db6-04a6719bbecc%40googlegroups.com?utm_medium=email&utm_source=footer
.
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Michael van Leest


Michael van Leest


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com?utm_medium=email&utm_source=footer
.

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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Sent from my Android device with K-9 Mail. Please excuse my brevity.


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.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/74BF5055-EDEB-427E-B785-8CA7ACC18842%40gmail.com
https://groups.google.com/d/msgid/lucee/74BF5055-EDEB-427E-B785-8CA7ACC18842%40gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwibHy87Ya3apzRCCy-6VM_CHv7pVmrOLhx2Zk5B8%2BaOQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwibHy87Ya3apzRCCy-6VM_CHv7pVmrOLhx2Zk5B8%2BaOQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Regards,

Pritesh Patelhttp://www.thecfguy.com http://www.thecfguy.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

Sorry… um…

There are two elements of a session which need to be considered:

  1. lifecycle management
  2. storage

These are separate considerations.

Lifecyle management is the whole “start a session” (this does whatever is
needed to create a session, and fires onSessionStart()), “track session
idle time”, “end a session” (this does whatever is necessary to end a
session, and fires onSessionEnd().

Storage is… where the session data go.

The lifecyle stuff is Lucee’s job. The storage might be Lucee’s job too, or
it might be seconded off to a cache or a DB or [some other
storage-brokering agent]. What the storage for the session data is is
immaterial to the session itself.

It sounds to me - and I hope I’m wrong here - that what you said is when
using some non-Lucee storage mechanism, you’re also offloading session
management to that mechanism too. This strikes me as being very dodgy
coupling, and a less-than-ideal conflation of two separate concerns.

Is that more clear?On Wednesday, 18 March 2015 12:00:26 UTC, Micha wrote:


Adam

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 storage
  2. make pulls every x seconds to find out if a sessions have ended
  3. 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.

  1. 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.On Thursday, 19 March 2015 09:23:06 UTC, Micha wrote:


Adam

between the lines

Micha

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
    storage
  2. make pulls every x seconds to find out if a sessions have ended
  3. 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.

  1. 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…

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.

in the curretn implementation we only have parts of the session in the
memory, Lucee decides on it’s own when session get removed from emory based
on the memory available.
with this solution we would still hold the metadata of all session in
memory …On Fri, Mar 20, 2015 at 9:17 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 19 March 2015 09:23:06 UTC, Micha wrote:

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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/079b806e-da4c-4245-9639-95e0bcc803f5%40googlegroups.com
https://groups.google.com/d/msgid/lucee/079b806e-da4c-4245-9639-95e0bcc803f5%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Just found this in my inbox from ages ago. Didn’t get around to following
it up.On Friday, 20 March 2015 09:28:36 UTC, Micha wrote:

between the lines

Micha

On Fri, Mar 20, 2015 at 9:17 AM, Adam Cameron <dac...@gmail.com <javascript:>> 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
    storage
  2. make pulls every x seconds to find out if a sessions have ended
  3. 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.

  1. 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…

Well this is what I was getting at when I suggested that session
management is two things:

  1. managing the metrics / metadata of the session
  2. the storage

It seems you’re conflating the two, whereas I think only the storage part
of it should have location alternatives (in memory, in the DB, etc). Sorry
to repeat myself, but you didn’t seem to acknowledge that I said that
before, instead deciding to shift the direction of your response in another
direction.

Anyway, in that way it should always be within Lucee’s control to manage
session timeouts & knowing when event handlers need to be fired, etc.


Adam