Forum OpenACS Development: Re: caching ns_sets

Collapse
3: Re: caching ns_sets (response to 1)
Posted by Ola Hansson on 12/10/02 03:52 PM
Maybe adding a bolean (optional) "-persist" flag to db_list_of_ns_sets would be a good thing. That way you could make it call "ns_set copy -persist $selection" internally, or without -persist if you leave out the flag.

list_users_not_cached should also take the optional -persist flag, and the flag should be provided when it gets called from a memoization statement.

We would be able to do without my hack above if we implement it this way, I think.

The persistent ns_set needs to be freed at some point, but I haven't thought about that part so much yet... Some help here would be appreciated😊

Collapse
4: Re: caching ns_sets (response to 3)
Posted by Jeff Davis on 12/10/02 04:31 PM
You can't cache ns_sets with ns_cache even with the -persist flag. ns_sets are thread local and the ns_cache used by util_memoize is not. Even if you use a thread local cache there is no way to free the ns_set if the handle gets flushed. And besides, you don't want to cache this on a per thread basis. Anyway, I think unless there is some really good reason to use ns_sets (and I don't see one having looked at how this is being used), I think you would be better off caching a list of lists anyway.
Collapse
7: Re: caching ns_sets (response to 4)
Posted by Dan Wickstrom on 12/10/02 07:06 PM
Jeff, you're statement about ns_sets is slightly incorrect.  ns_sets created with the -persist flag are not thread local.  The handle for a ns_set created with the -persist flag is stored in a static hashtable that is globally accessible.  Access to persistant sets is protected by a global mutex, so there shouldn't be a problem with accessing it from multiple threads.
Collapse
9: Re: caching ns_sets (response to 7)
Posted by Jeff Davis on 12/10/02 07:18 PM
My mistake.  Although I still think it's better to put the data
into a list and ns_cache for that although I guess if
it is indeed persistent you could put the handle in an
nsv or in an unlimited size/time ns_cache (keeping in
mind that there would then be no mechanism to flush
the cache other than by hand).