Confused about web2py sessions handling in the filesystem, versus the db handling.

[AlighaThor]

Hi. I'm experimenting for the first time (but I'm quite a bit old using this amazing framework :)) storing sessions in the DB instead the filesystem, as I always did. I'm monitoring those two behaviours and somehow it feels (at least for me) that the DB session handling is far away more efficient/manteinable than the filesystem session handling.

Look at this:

When using the filesystem handling:

1 - I go to my login form. A session file is created (for the form key I suposse.).

2 - Then I finally log in. Another session file is created.

3 - Next I log out. A new file is created or somehow "moved" or "deleted" from the directory "165".

4 - Next I log in again. This time my form action did not create any new file, but a new one after the log in.

5 - Everything is repeated again. I log out, then a new file is created.

Now let's see the DB behaviour:

1 - Login form. A session record is created.

2 - I log in. The same record remains, but instead, as we expect, the unique_key is updated.

3 - I log out. Again, the record remains and the unique_key field is updated.

(Updated: My bad, after the log out, the record is deleted and a new one is created. I did'nt notice the new ID "17".)

Whatever I do, only one record is stored according my session origin (IP, Browser, etc) and this remains true until my session expires or is deleted.

Maybe I'm talking nonesenses, but it is feel "better" to me, having a "true one instance per session", using the DB, that many files/folders created over and over again related to the same origin using the filesystem.

What I am missing here? 

Is this the normal/expected behaviour when the default FS session handling is used? 

Can we consider that is more performant using the DB alternative that the FS one?

BTW: It seems that the admin option to "cleanup" only clear the sessions store in the filesystem, not the DB alternative.

Thanks for reading!

[Richard Vézina]

About session clean up, I recently set it in place (finally) and I can assure you that db sessions get cleared as expected.

About the FS sessions, I can say for sure but maybe it faster to just create another file than search the exsting file, then append or rewrite part of it... 

Finally it surely more performant to use db sessions as it is propose in the book as a way to help improve performance and scaling the work load your app can support.

Set a cron job with sessions clean up is also important as it make just sens that filtering over 10 db records vs thousand of them doesn't take the same amount of time and processing.

Richard

On Tue, Apr 3, 2018 at 1:01 PM, AlighaThor <alighathor...@gmail.com> wrote:

Hi. I'm experimenting for the first time (but I'm quite a bit old using this amazing framework :)) storing sessions in the DB instead the filesystem, as I always did. I'm monitoring those two behaviours and somehow it feels (at least for me) that the DB session handling is far away more efficient/manteinable than the filesystem session handling.

Look at this:

When using the filesystem handling:

1 - I go to my login form. A session file is created (for the form key I suposse.).

2 - Then I finally log in. Another session file is created.

3 - Next I log out. A new file is created or somehow "moved" or "deleted" from the directory "165".

4 - Next I log in again. This time my form action did not create any new file, but a new one after the log in.

5 - Everything is repeated again. I log out, then a new file is created.

Now let's see the DB behaviour:

1 - Login form. A session record is created.

2 - I log in. The same record remains, but instead, as we expect, the unique_key is updated.

3 - I log out. Again, the record remains and the unique_key field is updated.

Whatever I do, only one record is stored according my session origin (IP, Browser, etc) and this remains true until my session expires or is deleted.

Maybe I'm talking nonesenses, but it is feel "better" to me, having a "true one instance per session", using the DB, that many files/folders created over and over again related to the same origin using the filesystem.

What I am missing here? 

Is this the normal/expected behaviour when the default FS session handling is used? 

Can we consider that is more performant using the DB alternative that the FS one?

BTW: It seems that the admin option to "cleanup" only clear the sessions store in the filesystem, not the DB alternative.

Thanks for reading!

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[AlighaThor]

Well, I will stick with DB sessions from now.

Thanks!

[Richard Vézina]

DB sessions are so much more convenient... you only need one connection, not need to access remote server or sudo password etc...

Walk the extra mile and set a cron job for session2trash clean up and you now have one less thing to check for...

Depending on your workload, you don't have to do clean up as often than 5 min interval. 

Here my conf :

# CRON /etc/crond.d/

# m  h  dom mon dow user     command

  0  8-17/1 * * 1-5 root     /opt/scripts/sessions2trash.sh

# Bach script

python /home/www-data/web2py/web2py.py -S APPNAME -M -R scripts/sessions2trash.py -C -A -o

# -A : should be followed by a list of arguments to be passed to script, to be used with -S, -A must be the last option

# -o : args passed to sessions2trash.py which "Delete sessions, then exit."

#      NOTE  if it's omitted, processes get spawned but not killed

Good luck

Richard

On Wed, Apr 4, 2018 at 11:06 AM, AlighaThor <alighathor...@gmail.com> wrote:

Well, I will stick with DB sessions from now.

Thanks!

--

[Anthony]

One potential downside of db sessions is that you can have race conditions, as the session record does not get locked (unless something has changed). On the plus side, if you have multiple Ajax requests that all just need to read (but not write to) the session, they can be handled simultaneously (with file based sessions, because the session file is locked by each request, multiple Ajax requests must be handled one at a time, which is safer, but also slower).

Anthony

On Wednesday, April 4, 2018 at 1:28:18 PM UTC-4, Richard wrote:

DB sessions are so much more convenient... you only need one connection, not need to access remote server or sudo password etc...

Walk the extra mile and set a cron job for session2trash clean up and you now have one less thing to check for...

Depending on your workload, you don't have to do clean up as often than 5 min interval. 

Here my conf :

# CRON /etc/crond.d/

# m  h  dom mon dow user     command

  0  8-17/1 * * 1-5 root     /opt/scripts/sessions2trash.sh

# Bach script

python /home/www-data/web2py/web2py.py -S APPNAME -M -R scripts/sessions2trash.py -C -A -o

# -A : should be followed by a list of arguments to be passed to script, to be used with -S, -A must be the last option

# -o : args passed to sessions2trash.py which "Delete sessions, then exit."

#      NOTE  if it's omitted, processes get spawned but not killed

Good luck

Richard

[Richard Vézina]

Hello Anthony,

Is that normal that multiples sessions files get created in case of FS sessions??

Regards

Richard

[Anthony]

This behavior is controlled by the following auth.settings:

renew_session_onlogin (default=True)
keep_session_onlogin (default=True)
renew_session_onlogout (default=True)
keep_session_onlogout (default=False)

Renewing the session causes a new session ID and therefore file to be created -- that explains why the new files are created on both login and logout.

Keeping the session means that the content of the session is retained when the session is renewed. If keep is set to False, then the old file is deleted when the session is renewed (but the old file is not deleted when the keep is set to True). That explains why the old file is deleted on logout but not on login (given the above noted defaults). I believe this should probably be considered a bug -- the old file should be deleted in either case (the problem is that in the code, the file deletion happens in the same method that clears the session data, and of course that method is not called when the session is kept). Feel free to file a Github issue about this and refer back to this thread.

For now, if you don't need to retain any session data upon login (i.e., session data stored before login does not need to remain available once logged in), then you can set auth.settings.keep_session_onlogin=False, and the old session file will be deleted upon login (so, at any given time, there will be only one session file for a given user session).

Alternatively, of course you can set either or both of the renew_session_* settings to False, and no additional session files will be created on login or logout.

Anthony

[Richard Vézina]

Thank you Anthony as always very clear explanations.

:)

Richard

--

[AlighaThor]

Sorry for my delay. Thanks both Anthony and Richard for your excellent explanations!

Well, I changed for now to DB sessions. The settings mentioned by Anthony about renewing sessions are great, I did'nt know that. Anyway I still found that DB handling is by far easier/scalable/performant to me. :)

About locking sessions, I see there is a "locked" boolean field in the sessions table. What's stands for? I mean, I expect that it has something to do with sessions locking, but when and where it is triggered?

Thanks again guys!

[Anthony]

About locking sessions, I see there is a "locked" boolean field in the sessions table. What's stands for? I mean, I expect that it has something to do with sessions locking, but when and where it is triggered?

As far as I can tell, that field is not actually used for anything. Maybe it was intended to allow locking, but the functionality was never implemented.

Anthony