|
When a POA creates an object reference, it encapsulates it within an IOR (Interoperable Object Reference).
Whether an IOR is transient or persistent is determined at IOR creation time by the server application code.
The POA’s lifespan policy determines whether object references are transient or persistent.
A transient object reference continues to work only for as long as its associated server process is available. Once the server terminates, a transient object reference never works again, even if the server is restarted
A persistent object reference is one that a client can successfully reissue over successive instantiations of the target server and POA.
You specify a POA’s lifespan policy by calling create_lifespan_policy() with one of these arguments:
- TRANSIENT: (default policy) Object references do not outlive the POA in which they are created. After a transient object’s POA is destroyed, attempts to use this reference yield the exception CORBA::OBJECT_NOT_EXIST.
- PERSISTENT: Object references can outlive the POA in which they are created.
Transient object references
If the POA has a TRANSIENT policy, the IOR contains the server process’s host address and port and a unique object key. Consequently, that object reference is valid only as long as the server process remains alive. Once the server process terminates, the object reference becomes invalid and it never works again, even if the server is restarted on the same host and port.
Persistent object references
If the POA has a PERSISTENT policy, the IOR contains the address of the location domain’s implementation repository, which maps all servers and their POAs to their current locations. Given a request for a persistent object, the location daemon uses the object’s “virtual” address first, and looks up the server process’s actual location via the implementation repository.
An ORB binds transient references differently from persistent references.
|
