How about this? Not extremely efficient perhaps, but you wouldn't have to change any other code...

ad_proc -public list_users {
        {-rel_type dotlrn_member_rel}
        community_id
    } {
        Returns the list of users with a membership_id, a user_id, 
first name,
        last name, email, and role.

        AKS: uncaching this until we figure out how to cache ns_sets 
correctly
    } {
#        return [dotlrn_community::list_users_not_cached \
#            -rel_type $rel_type \
#            -community_id $community_id
#        ]

        set users_list [util_memoize "dotlrn_community::list_users_not_cached \
            -rel_type $rel_type \
            -community_id $community_id
        "]

        # Convert to a list of ns_sets

        set ns_sets [list]

        foreach kv_pairs_list $users_list {
            lappend ns_sets [util_list_to_ns_set $kv_pairs_list]
        }

        return $ns_sets
    }



    ad_proc -private list_users_not_cached {
        {-rel_type:required}
        {-community_id:required}
    } {
        Memoizing helper
    } {
#       return [db_list_of_ns_sets select_users {}]

        set result [list]

        foreach ns_set [db_list_of_ns_sets select_users {}] {
            lappend result [util_ns_set_to_list -set $ns_set]
        }

        return $result
    }

Disclaimer: I have only tested it in parts...

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.

Jeff,

That is interesting, I use ns_set -persist in a startup script in AOLserver3.4, and it seems to work fine in all threads. I think I use it in init.tcl, so maybe it happens before thread creation?

Of course you still have to use the old ns_share, or new nsv_* to use it later on.

If I had to write this code over again, I would use nsv_array instead of ns_set, unless I needed multiple values per key.

If ns_set is always thread local, that seems like a mistake if the -persist flag is to be of any use. Ns_set offers some unique features, and is almost as fast as nsv arrays, at least for small to medium set sizes. But maybe the problem is one structure accessed by multiple threads with no protection?

If you are going to be looping over the set members, nsv is still efficient, because you can make an copy of the array so you only lock a mutex once pre copy.

Maybe the cacheing procedures could create an array, bulk copy that array to an nsv_array in a single step, and then return a copy of this nsv_array when needed.

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).

that is exactly the format I think is better :)


The patch instructions are at:
http://openacs.org/bugtracker/openacs/patch-submission-instructions.html
(although I guess I should update it since I left out that
diff -uN does not always work since solaris only has diff -c
style context diffs).

Hi Don,

Will db_list_of_ns_sets having caching too?  I was hoping it will.  Originally I tried to use db_list_of_lists since there are something that db_multirow is not good at.  But then due to some limitation of db_list_of_lists I ended up making a patched version.  I then decide to drop the patched up db_list_of_lists in favor or stock db_list_of_ns_sets.  So I am using db_list_of_ns_sets which fits the bill perfectly and I am assuming my caching issue will be solved one you get your caching db_*.  Will db_list_of_ns_sets have a caching feature in the future?