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

Collapse
8: Re: Using the function "ad_set_client_property". (response to 1)
Posted by Jorge Couchet on 09/24/07 04:28 PM
Well,

The problem with ad_set_client_property (some session variable's values are lost), indeed was solved increasing the kernel parameter Caching/MaxSize's default value.

Now I have two solutions implemented:

a) Using the database in order to save temporary values
b) Using the ad_set_client_property (with MaxSize increased)

Pros/cons of both solutions: I suppose that I get more performance with "b" (in special if it's using the switch "-persistent f"), and the solution "a" is more secure (I do not have the risk of reaching MaxSize and losing some values again).

Regards,

Jorge.

Collapse
11: ad_set_client_property uses ns_cache? (response to 8)
Posted by Andrew Piskorski on 09/25/07 12:18 PM
So ad_set_client_property is implemented with ns_cache? Yes, I see that it is so (via util_memoize_seed). Is that really appropriate?

Seems to me that client properties should have their own cache, not the util_memoize cache, which is bounded on time but not on size. Does ns_cache support that style of use? (Or, perhaps keep the space bound, but make sure it's very large, and separate from whatever cache util_memoize uses?) You want non-persistent client properties to expire after a time, but while they're active you don't want AOLserver to throw them out just because they're large, right? Thoughts?

I'm not clear though, what happens if non-persistent client properties are evicted from the cache? Or if the AOLserver restarts, for that matter? What will the Tcl code and end user see?

Collapse
12: Re: ad_set_client_property uses ns_cache? (response to 11)
Posted by Tom Jackson on 09/26/07 05:53 AM
Well, util_memoize isn't storage. If you can't guarantee a particular lifetime for the data, it isn't really a programming model. I can't think of a single reason to use util_memoize for storing a single user's data. Data like this is essentially private and shouldn't be stored in a global structure. The closest concept is a session variable, which should be stored somewhere for a guaranteed length of time, or until the session is expired by client or server. But if the data is personally valuable, maybe it should be stored so that the user can decide to either commit it to the larger database, delete it, or just let it stay around for a later decision. Caching should probably not be part of this process, as caching implies that there is a master copy somewhere.
Collapse
13: Re: ad_set_client_property uses ns_cache? (response to 12)
Posted by Jorge Couchet on 09/26/07 03:35 PM
Hi,

In order to guarantee the permanence of the data I'm using the database. I have created the following table:

------ *******************************************
------ *******************************************
------ start SESSION_VARIABLES
------ *******************************************
------ *******************************************

-- start table SESSION_VARIABLES

CREATE TABLE session_variables (
session_id integer,
module_id varchar,
var_name varchar,
var_value varchar CONSTRAINT session_variables_var_value_nn
NOT NULL,
CONSTRAINT session_variables_pk
PRIMARY KEY(session_id, module_id, var_name)
);

COMMENT ON TABLE session_variables IS '
The table holds session variables. The programmer is in charge to delete the variables rows, if not the data is holded permanently.
';

COMMENT ON COLUMN session_variables.session_id IS '
The session ID of the user (obtained with the command [ad_conn session_id]).
';

COMMENT ON COLUMN session_variables.module_id IS '
The package key plus the package id ( "package_key_[ad_conn package_id]").
';

-- end table SESSION_VARIABLES

------ *******************************************
------ *******************************************
------ end SESSION_VARIABLES
------ *******************************************
------ *******************************************

I don't know if there is a better model, but this one is working fine to me.

Regards,

Jorge.