Persistent Object Id's after registering objects using Servant Manager

Persistent Object Id's after registering objects using Servant Manager

Post by Aditya Sin » Sat, 01 Mar 2003 10:18:28



I am using servant manager for registering my servants. Here I am
setting RequestProcessingPolicy as well as ServantRetentionPolicy. In
order to have persistent object Id's, I tried using  lifespan_policy
and id_assignment_policy along with the above 2 policies, but it
didn't work.

Is there any way, I can register my servants by using servant manager
so that it generates persistent object Id's??

Thank you.

Aditya

 
 
 

Persistent Object Id's after registering objects using Servant Manager

Post by Aditya Sin » Sat, 01 Mar 2003 10:22:00


I am using servant manager for registering my servants. Here I am
setting RequestProcessingPolicy as well as ServantRetentionPolicy. In
order to have persistent object Id's, I tried using  lifespan_policy
and id_assignment_policy along with the above 2 policies, but it
didn't work.

Is there any way, I can register my servants by using servant manager
so that it generates persistent object Id's??

Thank you.

Aditya

 
 
 

1. Object Key, Object ID, Object Reference !!

Either a client, or a server acting as a client to another server,
may want to store persistent IORs.  A server that references only
the objects that it implements itself can theoretically convert
any persistent IOR's that it is holding back into the application
specific native form before storing it in the database.

One application of two CORBA servers would be to achieve fine
grain integration two large databases via CORBA.  Some of the
foreign keys in one database would be persistent IOR's pointing
to the other database, and vice versa.

The criticism I've encountered is that CORBA is ill suited for this
kind of application because of all the hoops you have to jump
through (and rules you have to break) to make compact reliable
foreign keys out of persistent IORs without incurring excessive
I/O for the conversions. CORBA seems suitable for doing this
only on a very small scale where I/O for conversions is not a problem,
and the database is small enough that a significant portion can
be cached, so that the cached objects holding references hang around
long enough to make resolving the persistent IORs involving the
FORWARDing I/O cost effective (which is done once per reference called
per loading of a cached object (servant)).

On the large scale, the prevailing philosophy seems to be to forget
about using CORBA as a vehicle of database integration, and just use
two databases from the same vendor and then use that vendor's
proprietary method of database integration.  Of course this
assumes that you are indeed free to choose databases and have the
necessary control over them.

--Jeff

2. Clients crashes when opening database on server

3. administrator console and sms 2.0

4. Accessing actual servant object from corba interface object

5. easy access

6. Persistent Object Id ...

7. XGEDIT95 serial number search

8. 'destroy' for servant and object

9. Why Servant manager a CORBA object?

10. Why are servant managers CORBA objects

11. Persistent Object Graphics Not Persistent in Resizeable Windows

12. Problem using CORBA::ORB object after using 'shutdown' method