org.omg.Messaging
Interface RebindPolicy
- All Superinterfaces:
- IDLEntity, LocalInterface, Object, Policy, PolicyOperations, RebindPolicyOperations, java.io.Serializable
public interface RebindPolicy
- extends LocalInterface, RebindPolicyOperations, Policy, IDLEntity
This policy is used to indicate
whether the ORB may transparently rebind once successfully bound to a target. For
GIOP-based protocols an object reference is considered bound once it is in a state
where a LocateRequest message would result in a LocateReply message with status
OBJECT_HERE. If the effective Policy of this type has a rebind_mode value of
TRANSPARENT, the
ORB will silently handle any subsequent LocateReply messages with
OBJECT_FORWARD status or Reply messages with LOCATION_FORWARD status.
The effective policies of other types for this object reference may change from
invocation to invocation. If the effective Policy of this type has a rebind_mode value
of NO_REBIND, the ORB will raise a REBIND system exception if any rebind
handling would cause a client-visible change in policies. This could happen under the
following circumstances:
- The client receives a LocateReply message with an OBJECT_FORWARD status
and a new IOR that has policy requirements incompatible with the effective policies
currently in use.
- The client receives a Reply message with LOCATION_FORWARD status and a
new IOR that has policy requirements incompatible with the effective policies
currently in use.
If the effective Policy of this type has a rebind_mode value of NO_RECONNECT,
the ORB will raise a REBIND system exception if any rebind handling would cause a
client-visible change in policies, or if a new connection must be opened. This includes
the reopening of previously closed connections as well as the opening of new
connections if the target address changes (for example due to a
LOCATION_FORWARD reply). For connectionless protocols, the meaning of this
effective policy must be specified, or it must be defined that NO_RECONNECT is an
equivalent to NO_REBIND. Regardless of the effective RebindPolicy, rebind or
reconnect can always be explicitly requested through an invocation of
CORBA::Object::validate_connection
. When instances of RebindPolicy are created,
a value of type RebindMode is passed to CORBA::ORB::create_policy
. This policy
is only applicable as a client-side override. When an instance of RebindPolicy is
propagated within a PolicyValue in an INVOCATION_POLICIES Service Context,
the ptype has value REBIND_POLICY_TYPE and the pvalue is a CDR
encapsulation containing a RebindMode.
The following table lists the behavior of the different RebindMode
policies:
Behavior resulting from RebindMode policies
RebindMode type |
Handling of closed connection to the same object |
Handling of object forwarding |
Handling of Object failover1 |
NO_RECONNECT |
No, throws REBIND exception. |
No, throws REBIND exception. |
No |
VB_NO_REBIND |
Yes |
No, throws REBIND exception. |
No |
NO_REBIND |
Yes |
Yes, if policies match.
No, throws REBIND exception.
|
No |
TRANSPARENT |
Yes |
Yes |
No |
VB_NOTIFY_REBIND |
Yes |
Yes |
Throws an exception after failure detection and then tries a failover on subsequent
requests. |
VB_TRANSPARENT |
Yes |
Yes |
Yes, transparently. |
1 The appropriate CORBA exception will be thrown in the case
of a communication problem or an object failure. |
- See Also:
com.inprise.vbroker.QoSExt.VB_TRANSPARENT
,
com.inprise.vbroker.QoSExt.VB_NO_REBIND
,
com.inprise.vbroker.QoSExt.VB_NOTIFY_REBIND
Methods inherited from interface org.omg.CORBA.Object |
_create_request, _create_request, _duplicate, _get_domain_managers, _get_interface_def, _get_policy, _hash, _is_a, _is_equivalent, _non_existent, _release, _request, _set_policy_override |
Read the latest documentation online