Forum OpenACS Development: Re: Using the function "ad_set_client_property".

Collapse
14: Re: Using the function "ad_set_client_property". (response to 1)
Posted by Dave Bauer on 09/26/07 08:48 PM
If you are going to do it use "text" not varchar, varchar has limits just like the URL.

Although you don't need to bother that's what sec_session_properties is for!

\d sec_session_properties
Table "public.sec_session_properties"
Column | Type | Modifiers
----------------+-----------------------+-----------
session_id | integer | not null
module | character varying(50) | not null
property_name | character varying(50) | not null
property_value | text |
secure_p | boolean |
last_hit | integer | not null
Indexes:
"sec_session_properties_pkey" PRIMARY KEY, btree (session_id, module, prope\
rty_name)
"sec_property_names" btree (property_name)

This is where ad_set_client_property values are stored.

All you data should be in here all the time. I guess the bug is that you can get a partial result from ad_get_client_property is the cache is full? But you should always be able to get it back out of the database.

Collapse
15: Re: Using the function "ad_set_client_property". (response to 14)
Posted by Jorge Couchet on 09/26/07 09:06 PM
Hi Dave,

Indeed, the problem would seem to happen when the cache is full (at least it is solved when I have increased the kernel parameter MaxSize).

"But you should always be able to get it back out of the database": this means that I must explicitly query he table sec_session_properties (in order to avoid the error -lost values- that I get using ad_get_client_property)?

Thanks a lot for your help!

Jorge.

Collapse
16: Re: Using the function "ad_set_client_property". (response to 14)
Posted by Tom Jackson on 09/27/07 02:47 AM

Caching session data is probably a bug. One reason to place session data into the database is so that you can transparently move from one front-end server to multiple servers. It isn't expensive if you have few users, and if you have many, another front-end server shouldn't be expensive either.

Caching should really be reserved for shared data. Even dynamic data can be cached for a short period of time. I imagine that you could cache most website front pages and index pages for a few minutes at least without any impact on the dynamic appearance of the site.

And if you can't turn off caching during development, why not just pull out a gun and get it over with? Turning on caching is like turning off logging. Maybe another concept is that you shouldn't have to test your package to see if it fails when using a cache. If the cache is not your code, it probably points to a bug in the code using a cache.

Maybe there is another way of putting it: don't cache inputs or intermediate results. Cache results which are likely to be valid for a useful amount of time.