Re: Implementation Repository

James Waller wrote:

>Right, but I believe that even having to make a
>separate call to the ImR to get an IOR for every
>object (regardless of whether the ImR stores anything)
>will adversely affect scalability. If a server wants
>to publish a ton of object references, that's still a
>lot of calls to the ImR which makes it become more of
>a bottleneck. However, maybe a way to (at least
>partially) alleviate this would be to allow the server
>to get IORs en masse by making one call to the ImR
>with a whole load of object references.
>  
>

Each time a distinct client uses one of the indirect references, it hits 
the ImR first.  I would think this would happen as much or more often 
than generation of the references in the first place, and so you may be 
avoiding a small percentage of the load the ImR will face.  I just 
measured my prototype at 600 indirect reference creations/sec.  That's 
on a 450 MHz pII running lots of other desktop stuff too.  I like the 
batch request idea.  If the result of a database request is to be 
returned as a bunch of indirect persistent references, then it makes a 
lot of sense for the ImR to handle them in one go.

But hey, if the interceptor is already written to do the job, I won't 
argue.  One of my goals is for the ImR to work with C++ and Python 
servers.  Can the interceptor be installed in a Python server?

Kendall