Forum OpenACS Development: caching ns_sets

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
    }

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.

The patch instructions are at:
https://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).

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?