onSessionEnd doesn't call if using sessionstorage to database

[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

[Brad Wood]

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

[Pritesh]

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 

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

[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

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

[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...

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxu8_t%2BtqGx6KXsq2qKNPMbRthgDJGWuXRRiZQK4vYSxg%40mail.gmail.com.

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

--

Michael van Leest

[Michael van Leest]

@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

--

Michael van Leest

[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: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.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 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/CAMaJE6u-dFrs2g6PkWHvhdW7nkmKfG2H9ETBbG_fMUvAZnrJsg%40mail.gmail.com.

[Michael van Leest]

@Brad, I misread the question and was focused on the session data part. 

It all makes sense about not having the onSessionEnd part.

Mike

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.

--
Sent from Gmail Mobile

[Michael Offner]

Thanks for the translation from Swiss to US English ;-) 

That is exactly the point!

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CALbQ1om8tgTVBS1ps3YfV1sTnr_3NGZvxX2K%3D9u1phAi1KjKgQ%40mail.gmail.com.

[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?

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

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

[Pritesh Patel]

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.

[Michael Offner]

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 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/74BF5055-EDEB-427E-B785-8CA7ACC18842%40gmail.com.

[Pritesh Patel]

Got it... Thanks 

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBwibHy87Ya3apzRCCy-6VM_CHv7pVmrOLhx2Zk5B8%2BaOQ%40mail.gmail.com.

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

--

Regards,

Pritesh Patel
http://www.thecfguy.com

[Adam Cameron]

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

[Michael Offner]

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.

Micha

--

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.

[Adam Cameron]

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.

 

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

[Michael Offner]

between the lines

Micha

On 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 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.

 

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

 

 

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

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.

[Adam Cameron]

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

 

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

 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