Re: [web2py] Re: Confused about web2py sessions handling in the filesystem, versus the db handling.

[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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [web2py] Re: Confused about web2py sessions handling in the filesystem, versus the db handling.

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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [web2py] Re: Confused about web2py sessions handling in the filesystem, versus the db handling.

[Richard Vézina]

Thank you Anthony as always very clear explanations.

:)

Richard

On Wed, Apr 4, 2018 at 5:19 PM, Anthony  wrote:

> 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
>
> On Tuesday, April 3, 2018 at 1:01:21 PM UTC-4, AlighaThor 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.
>>
>>
>>
>> 
>>
>>
>> (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