Yes, exactly right. The scope is intended to be module init to
shutdown, and across all callers. I don't really know how I could do
otherwise - a per-request cache would be throwing away all the

Of course you have worried me now. If the keys are chosen poorly - for
example every call chooses key "my_first_key" or suchlike - then that
is a recipe for disaster. The key needs to correspond to the set of
types that are loaded into that DAS: the keys must be chosen so that
if the model is different, so is the key. I can't enforce that, of
course, all I can do is use it that way throughout the SCA code.

On Mar 23, 1:52 pm, "cem" <[EMAIL PROTECTED]> wrote:
> This discussion thread hasn't explicitly spelled out the scope of the
> cache, but I've been assuming that we're intending it to endure from
> module init to module shutdown. In other words, depending on the SAPI,
> the cache entries may be available to multiple independent SCA
> programs, sequentially and simultaneously.
> Did I get this wrong? I can see how the interface you describe would
> work for a request-scoped or possibly thread-scoped cache. But it
> doesn't feel right to me to hand out the task of key management to
> uncoordinated applications. Imagine if everyone used the same key
> string that's in the example code snippet :-) Please put me right.

You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to