The cache is either stored in a file or in volatile memory

[Lorenzo Gil Sanchez]

Right now, when you instantiate a Client object it accept a persistent_cache argument. This is used to create a Population object which will use it to create a Cache object. When the argument reach this point the cache is either stored in a file or not persisted at all.

This cache thing is neccesary to perform the logout since this is the link in pysaml2 between a session initiated in the authenticate step and the logout process. But my problem is that being a file is not very efficient or robust when you have an SP used concurrently by a lot of users. How are the concurrent accesses to the cache file handled?

I would prefer to store that information in other places like a Memcache server. So if I instantiate a Client object and pass a persistent_cache object different than None, it should be treated as a Cache object and not as a filename or something like this.

[Roland Hedberg (roland-hedberg)]

On 8/5/10 22:09, Lorenzo Gil Sanchez wrote:
> Public bug reported:
>
> Right now, when you instantiate a Client object it accept a
> persistent_cache argument. This is used to create a Population object
> which will use it to create a Cache object. When the argument reach this
> point the cache is either stored in a file or not persisted at all.
>
> This cache thing is neccesary to perform the logout since this is the
> link in pysaml2 between a session initiated in the authenticate step and
> the logout process. But my problem is that being a file is not very
> efficient or robust when you have an SP used concurrently by a lot of
> users. How are the concurrent accesses to the cache file handled?
>
> I would prefer to store that information in other places like a Memcache
> server. So if I instantiate a Client object and pass a persistent_cache
> object different than None, it should be treated as a Cache object and
> not as a filename or something like this.
>
Good idea !

So, we only have to decide which functionality a Cache object
should/must implement.

-- Roland

[Roland Hedberg (roland-hedberg)]

On 8/6/10 17:22, Roland Hedberg wrote:
> On 8/5/10 22:09, Lorenzo Gil Sanchez wrote:
>
>> Public bug reported:
>>
>> Right now, when you instantiate a Client object it accept a
>> persistent_cache argument. This is used to create a Population object
>> which will use it to create a Cache object. When the argument reach this
>> point the cache is either stored in a file or not persisted at all.
>>
>> This cache thing is neccesary to perform the logout since this is the
>> link in pysaml2 between a session initiated in the authenticate step and
>> the logout process. But my problem is that being a file is not very
>> efficient or robust when you have an SP used concurrently by a lot of
>> users. How are the concurrent accesses to the cache file handled?
>>
>> I would prefer to store that information in other places like a Memcache
>> server. So if I instantiate a Client object and pass a persistent_cache
>> object different than None, it should be treated as a Cache object and
>> not as a filename or something like this.
>>
>>
> Good idea !
>
> So, we only have to decide which functionality a Cache object
> should/must implement
>
The interface is defined in cache.py .
I change the code to accept None in which case it will be a
non-persistent storage or a pointer to an object that adheres to the
Cache interface.

-- Roland

[Lorenzo Gil Sanchez (lgs)]

2010/8/6 Roland Hedberg <email address hidden>:
> On 8/6/10 17:22, Roland Hedberg wrote:
>> On 8/5/10 22:09, Lorenzo Gil Sanchez wrote:
>>
>>> Public bug reported:
>>>
>>> Right now, when you instantiate a Client object it accept a
>>> persistent_cache argument. This is used to create a Population object
>>> which will use it to create a Cache object. When the argument reach this
>>> point the cache is either stored in a file or not persisted at all.
>>>
>>> This cache thing is neccesary to perform the logout since this is the
>>> link in pysaml2 between a session initiated in the authenticate step and
>>> the logout process. But my problem is that being a file is not very
>>> efficient or robust when you have an SP used concurrently by a lot of
>>> users. How are the concurrent accesses to the cache file handled?
>>>
>>> I would prefer to store that information in other places like a Memcache
>>> server. So if I instantiate a Client object and pass a persistent_cache
>>> object different than None, it should be treated as a Cache object and
>>> not as a filename or something like this.
>>>
>>>
>> Good idea !
>>
>> So, we only have to decide which functionality a Cache object
>> should/must implement
>>
> The interface is defined in cache.py .
> I change the code to accept None in which case it will be a
> non-persistent storage or a pointer to an object that adheres to the
> Cache interface.
>

Great, I think that way is so much more flexible and useful. I'll
probably write two implementations of the Cache interface: one that
save the stuff in a database table and another one that uses a
Memcached server. I'll let the user to choose which one he wants to
use via a Django settings preference.

[Roland Hedberg (roland-hedberg)]

On 8/6/10 19:47, Lorenzo Gil Sanchez wrote:
> 2010/8/6 Roland Hedberg <email address hidden>:
>
>> On 8/6/10 17:22, Roland Hedberg wrote:
>>
>>> On 8/5/10 22:09, Lorenzo Gil Sanchez wrote:
>>>
>>>
>>>> Public bug reported:
>>>>
>>>> Right now, when you instantiate a Client object it accept a
>>>> persistent_cache argument. This is used to create a Population object
>>>> which will use it to create a Cache object. When the argument reach this
>>>> point the cache is either stored in a file or not persisted at all.
>>>>
>>>> This cache thing is neccesary to perform the logout since this is the
>>>> link in pysaml2 between a session initiated in the authenticate step and
>>>> the logout process. But my problem is that being a file is not very
>>>> efficient or robust when you have an SP used concurrently by a lot of
>>>> users. How are the concurrent accesses to the cache file handled?
>>>>
>>>> I would prefer to store that information in other places like a Memcache
>>>> server. So if I instantiate a Client object and pass a persistent_cache
>>>> object different than None, it should be treated as a Cache object and
>>>> not as a filename or something like this.
>>>>
>>>>
>>>>
>>> Good idea !
>>>
>>> So, we only have to decide which functionality a Cache object
>>> should/must implement
>>>
>>>
>> The interface is defined in cache.py .
>> I change the code to accept None in which case it will be a
>> non-persistent storage or a pointer to an object that adheres to the
>> Cache interface.
>>
>>
> Great, I think that way is so much more flexible and useful.
Totally agree !
> I'll
> probably write two implementations of the Cache interface: one that
> save the stuff in a database table and another one that uses a
> Memcached server. I'll let the user to choose which one he wants to
> use via a Django settings preference.
>
Would you mind if we put those in the main pysaml2 branch.
I should give you access to the main branch, will do when I find out how.

-- Roland