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

2018-04-11 Thread 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.

2018-04-11 Thread 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.

2018-04-05 Thread 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 DB alternative.
>>
>> T

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

2018-04-04 Thread 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

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