Demand-driven object loading

[Edward Scott]

Randy Shoup wrote:

> All --
>
>   We are looking into implementing a demand-driven approach to loading
> persistent objects in omniORB.  We would like to be able to periodically
> "age" objects out of a server-side cache, but have references to those
> objects remain valid.  When an unloaded object received a request, it
> would be loaded from a persistent store.  In looking through the
> maillist archives, I found the following references, where this issue
> was discussed:
>
> http://www.orl.co.uk/omniORB/archives/1997-Jun/0025.html
> http://www.orl.co.uk/omniORB/archives/1997-Jun/0027.html
>
>   In thinking about the issues, we were concerned that the forwarding
> approach would require us to have a potentially very large number of
> active objects -- at least a reDirector for each available object.  We
> are leaning toward the objectLoader approach, most particularly because
> it would allow us to control/minimize the number of active objects in
> the system at any one time.  Has anyone else done anything like this?
> Has anyone resolved these issues differently?
>
> Thanks very much,
> -- Randy
> _________________________________________________________________
> Randy Shoup                                     (415)569-3682
> Senior Software Developer                       rshoup@tumbleweed.com
> Tumbleweed Software Corporation

Dear Randy,

I too had concerns about the redirection mechanism. In the end I decided to
use a Orbix style loader mechanism. I implemented it for omniORB2 such that
when an object is not found a sequence of Loader objects attempt to load
the object until one succeeds or all Loaders have been tried. Each
omniORB object can have a loader assocaited with it which will be used for
saving when the server shuts down.

Loaders are written by inheriting from the loader class and implementing
two operations:

      omniObject *load (const omniObjectKey &key);
      void save (const omniObjectKey &key, omniObject *obj);

The Loaders are self registering (e.g. the constructor adds them to the
list).

I also added two operations to omniObject: setLoader and save. Adding the
save operation into the base object avoid the hacks found in some of the
other Orbs when the implementation of an abject needed to accessed :-)

I can send anyone who is interested the changes - however a couple of
points to bare in mind:

- I used an STL map in the loader mechanism which would have to be replaced
if you don't have STL (omniORB does not use STL)
- I have suspended using omniORB and as far as I recollect I was having
some problems with the saving mechanism (I wanted to store the object state
remotely and during the shutdown process I could not start a connection to
a remote server).

I still intend to continue using omniORB and will probably port my changes
to the new release when it comes out.

I'll post the mods to this list if there is sufficient demand...

Regards,

Edward Scott

--
-----------------------------------------------------------------------
Edward Scott ................Prism Technologies Ltd., Kingfisher House,
http://www.prismtech.co.uk ..Kingsway, Tyne & Wear, NE11 0JQ, England
Edward.Scott@prismtech.co.uk Tel +44(0)1914913983 Fax +44(0)1914913973
Nothern OO Programing & Systems SIG: http://www.prismtech.co.uk/~noops/