Persistent Objects

[Sai-Lai Lo]

>>>>> Edward Scott writes:

> The LOCATION_FORWARDING solution is obviously a good idea but is it an
> addition to what I was suggesting rather than an alternative? I still
> need to detect when the first operation is performed on a unrestored
> perstent object...

The redirect object in the example is the equivalent of a daemon or an object
loader. It is this object that detects the first operation that is
performed on an unrestored persistent object. The redirect object does not
need to be type-related to the persistent object, it just need to call a
factory that can instantiate the persistent object. 

By the way, the term "persistent object" may be a bit confusing. I use it
here to mean an object that has states stored in a persistent store.
In the previous messages, I use the term "persistent object" to mean an
object that a program instantiate with the same IOR in different runs. In
the example, the redirect object is the one that has to have the same IOR
in different runs.


Now what if we don't have any redirect object at all. Instead, if an
incoming request is directed towards an object that the ORB has no
knowledge of, the ORB calls into an application installed "loader" to find
and locate the object. This method of loading object is not supported by
omniORB. This approach has the disadvantage that requests send to invalid
or non-existing objects can not be rejected by the ORB but has to go pass
the application level "loader" just in case it is one that the loader can
instantiate. There is also concurrency issues that need to be addressed.
My gut feeling is this may be a can of worms that we better avoid.


Regards,

Sai-Lai

-- 
E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
                                        |       24a Trumpington Street
Tel:            +44 223 343000          |       Cambridge CB2 1QA
Fax:            +44 223 313542          |       ENGLAND