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
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at