[omniORB] Authentication; Garbage Collection

Alex Suzuki alex.suzuki at gmail.com
Mon Aug 2 11:13:32 BST 2004


Duncan,

On Fri, 23 Jul 2004 17:40:40 +0100, Duncan Grisby <duncan at grisby.org> wrote:
> The normal way with the evictor pattern is to use a servant locator.
> You really need to get Henning and Vinoski's book...

Thanks, it worked, and I got H&V's book in the meantime. It's
definitely more appealing
than the OMG specs!

There is, however, a caveat to their C++ implementation of the
eviction mechanism, they
use STL list and map data structures, map can be simulated with a
python dictionary,
but the list structure is more tricky.
They store an iterator for the eviction queue in their active object
map. Whenever a
request arrives for a servant that is in memory, the servant is moved
to the front (or
back, depending on queue semantics) of the queue. STL list iterators
are not invalidated
on insert/remove operations, so the other iterators stored in the
active object map
remain valid. If you'd simulate the evictor queue with a python list,
those "iterators"
(probably represented by indices) would become invalid.
At the moment, I do not modify the eviction queue, when a request is served from
memory. So it might happen that a servant is evicted which has just
served a request
but simply lived too long :-) In essence I only take servant age but
not liveness into
consideration.

Does anyone know if python offers a datastructure or module with
equivalent functionality
or if there is a better way to do this?

Again, I apologize that is not really an omniORB issue, but I think it
may be of interest
to some of the readers.

cheers, Alex
-- 
Alex Suzuki | as at cynox.ch | http://n.ethz.ch/student/asuzuki/
"Computer Science is no more about computers than astronomy
 is about telescopes." - E.W.Dijkstra



More information about the omniORB-list mailing list