thanks for your suggestion -- sounds reasonable. what i don't get is: why do i have to devise a scheme to serialize accesses to the cache create function if beaker cache already "implements a a multiple-reader/single-writer locking system so that multiple threads/processes can read the data while it will only be made a single time" as you say? isn't that exactly what a locking system is supposed to do? why do it another time?
@2 "Not sure what you need the session id for" -- i don't need it all. if there were sessions without a session id, i'd take that. if i could choose a session id myself, that would be just as fine, provided that session data is locked across multiple accessors. then, obviously, choosing any id that is guaranteed to be outside the set of automatically chosen session ids and using that same id in all accesses means you have created a globally accessible namespace that is guaranteed not to clash with any client-specific namespaces. i do not strive or require to use an id for that purpose, it is simply that the sessions mechanism presumably requires any persisted namespace to be registered using some string of characters. _wolf On Feb 20, 8:45 pm, Ben Bangert <[EMAIL PROTECTED]> wrote: > On Feb 20, 2008, at 8:19 AM, wolf wrote: > > > in fact, i'm all ready to either role my own pickling/shelving code > > including concurrency handling for file reading and writing or set up > > a database for the purpose. i already have code to handle concurrency > > and the rest is in python's standard lib. still, using beaker sessions > > would be nice as the code is probably much more proven to work across > > systems and situations than my own code would ever be, so there is > > some motivation to attempt code reuse / re-purposing here. > > Note that Beaker's cache object works like the sessions. Have you read > about using the cache object > diretly?http://wiki.pylonshq.com/display/pylonsdocs/Caching+in+Templates+and+... > > The Beaker cache implements a multiple-reader/single-writer locking > system so that multiple threads/processes can read the data while it > will only be made a single time. I believe it would work for your case > just fine. > > You will however need to do an additional check in the cache > createfunc, to ensure that no other caches are being created at the > same time in other namespaces (other domains), to make sure you only > have one whois lookup at a time running. I'd suggest a single whois > file lock or something similar to ensure that the createfunc's don't > run in parrallel. > > Not sure what you need the session id for. > > Cheers, > Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
