Re: Persisting data across authenticate <-> authorize ?

[prev] [thread] [next] [Date index for 2004/12/14]

Perrin,

Perrin Harkins wrote:

>Anything with individual TTL settings per item will let you do this.
>
>  
>
Right - I scoured the Cache::FastmMap perldoc and didn't see any way to 
do this.

>It doesn't normally go to disk with BerkeleyDB.  There's a shared memory
>cache.  Even things that just use the filesystem are really not going to
>disk on Linux, since they are effectively using the VM system as shared
>memory.
>
>  
>
Are you talking about the good ol' berk db (1.85) or the newer sleepycat 
versions? As for choice of OS, I use FreeBSD.

>Page-level locking would probably work better than that, but in my
>experience I never found the file-level locking in BerkeleyDB's simple
>mode to be an issue.
>
>  
>
My module is an authentication/authorization handler. It worked by 
issuing an access token that gets stored in one of an array of berkeley 
DB's. The browser then either sends the token back to the server in the 
form of a cookie or part of the query string. The token had an expiry on 
it, and every time the token was used, the TTL was updated.

So the first crack of the module there was significant lock contention - 
as every access to every part of the site required an exclusive lock. 
Then I put in the capability to 'not update token until x time has 
passed', so rather than updating the token at every access, it would 
only do it after a certain amount of time had passed.

This worked very well for me - I still found that to be kind of messy as 
I thought there should be a better way of keeping track of tokens other 
than disk access. When I was revamping the C module, I had considered 
writing a threaded daemon that would keep track of the tokens in memory, 
with a unix domain socket interface to the httpd processes. This has 
lots of advantages but is complex.

>I don't know how BerkeleyDB implements it, but it's in the C code, not
>in the Perl code.
>
>  
>
Yeah, I meant how the IPC::Shareable implements locking (well, 
IPC::SysV) - I realize this is done in C.

>The real problem with shared memory things like IPC::Shareable is that
>they have to serialize and de-serialize your entire data structure using
>Storable every time you read or write it.  They have no way to address
>individual entries.  The fast modules handle entries individually.
>
>  
>
I was planning on doing my own more efficent transformation to/from a 
scalar, and telling IPC::Shareable to not bother serializing it (I 
thought I read that this module could do that, but perhaps I was 
mistaken (maybe I was incorrectly thinking of Cache::FastMmap).

Thanks,
Tim


        -- 
        Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html