[TransWarp] Multiapp multithreaded server and configurable services

Phillip J. Eby pje at telecommunity.com
Fri Jun 20 12:50:33 EDT 2003

At 05:54 PM 6/20/03 +0200, Radek Kanovsky wrote:
>On Fri, Jun 20, 2003 at 11:35:17AM -0400, Phillip J. Eby wrote:
> > At 05:11 PM 6/20/03 +0200, Radek Kanovsky wrote:
> >
> > >But this ContactDM can have some classAttr (typicaly cache)
> > >that canot be shared on 'app2:/dm1' and 'app1:/svc1/dm11' occurences
> > >of ContactDM class. Obviously this components will be working on different
> > >databases or tables and cannot share cache.
> >
> > The answer is simple: don't use per-class caches.  Why can't you cache
> > using instance attributes instead?  Or if you need some sort of
> > application-wide cache, why not define a utility for the cache, and have
> > the instances look it up and bind to it?
>It could be the way but I want control caching per component. Some DM
>can hold all database table in memory while other don't. One application
>can have connection to more databases and oids can collide. And caches
>are not all that case. There is demand for other serviceAttrs.

If I understand your requirements correctly, you want to have shared caches 
for each application, but not shared *across* applications, just between 
threads for the same application.

So, your server needs to have a convention for an attribute name that will 
be copied across the root instances in the instance pool.  Let's say we 
call that attribute "sharedComponents".  Your server will set up the first 
instance of an application, and then take its 'sharedComponents' attribute, 
and pass it in as a keyword argument when constructing all other instances 
in the pool.  Thus, the sharedComponents object will be shared across all 

By defining other bindings in the app component, you can offer any 
subcomponent of 'sharedComponents' to the application tree.  For example:

     someSharedThing = binding.bindTo('sharedComponents/foo', 

This would offer sharedComponents.foo as an IFooService provider for 
anywhere in the application.

Using this approach, you could offer a "caching service" that provided 
cross-thread caches for individual components.

More information about the PEAK mailing list