Only certain policies that pertain to the invocation of an operation at the client end can be overridden using this operation. An attempt to override any other policy results in the raising of the CORBA::NO_PERMISSION exception. If the request would put the set of overriding policies for the target PolicyManager in an inconsistent state, no policies are changed or added, and the exception
InvalidPolicies is raised. There is no evaluation of compatibility with policies set within other PolicyManagers.
Returns the effective overriding Policy for the object reference. The effective override is obtained by first checking for an override of the specified PolicyType at the Object scope, then at the Current scope, and finally at the VisiBroker ORB scope. If no override is present for the requested
PolicyType, the system-dependent default value for that
PolicyType is used. Portable applications are expected to set the desired "defaults" at the VisiBroker ORB scope since default Policy values are not specified.
The effective override is then compared with the Policy as specified in the IOR. The effective Policy is the intersection of the values allowed by the effective override and the IOR-specified Policy. If the intersection is empty, the system exception INV_POLICY is raised. Otherwise, a Policy with a value legally within the intersection is returned as the effective Policy. The absence of a Policy value in the IOR implies that any legal value may be used. To ensure the accuracy of the returned effective Policy, invoke
non_existent or
validate_connection on an object reference prior to
get_policy. If
get_policy is invoked prior to the object reference being bound, the returned effective Policy is implementation-dependent. In that situation, a compliant implementation may do any of the following: raise the exception
CORBA::BAD_INV_ORDER, return some value for that
PolicyType which may be subject to change once a binding is performed, or attempt a binding and then return the effective Policy. Note that if the
RebindPolicy has a value of
TRANSPARENT, the effective Policy may change from invocation to invocation due to transparent rebinding.
This method works as does the PolicyManager method of the same name. However, this method updates the current set of policies of an Object, thread or the VisiBroker ORB with the requested list of Policy overrides. In addition, this method returns a
CORBA::Object whereas other methods of the same name return
void.
Returns the value TRUE if the current effective policies for the Object will allow an invocation to be made. If the object reference is not yet bound, a binding will occur as part of this operation. If the object reference is already bound, but current policy overrides have changed or for any other reason the binding is no longer valid, a rebind will be attempted regardless of the setting of any
RebindPolicy override. The
validate_connection operation is the only way to force such a rebind when implicit rebinds are disallowed by the current effective
RebindPolicy. The attempt to bind or rebind may involve processing GIOP
LocateRequests by the VisiBroker ORB.
This method returns the value FALSE if the current effective policies would cause an invocation to raise the system exception
INV_POLICY. If the current effective policies are incompatible, the out parameter
inconsistent_policies contains those policies causing the incompatibility. This returned list of policies is not guaranteed to be exhaustive. If the binding fails due to some reason unrelated to policy overrides, the appropriate system exception is raised.
The VisiBroker implementation of RebindPolicy is a complete implementation of
RebindPolicy as defined in the Messaging Specification with enhancements to support failover.
The RebindPolicy of the VisiBroker ORB determines how it handles GIOP location-forward messages and object failures. The VisiBroker ORB handles fail-over/rebind by looking at the effective policy at the
CORBA::Object instance.
The OMG implementation, derived from CORBA::Policy, determines whether the VisiBroker ORB may transparently rebind once it is successfully bound to a target server. The extended implementation determines whether the VisiBroker ORB may transparently failover once it is successfully bound to a target Object, thread, or VisiBroker ORB.
If set to TRUE, this policy changes this behavior; it causes the VisiBroker ORB to delay contacting the Object until the first invocation.
The RelativeConnectionTimeoutPolicy indicates a timeout after which attempts to connect to an object using one of the available endpoints is aborted. The policy value of unsigned longlong type specifies the timeout in 100s of nanoseconds. It is applied to every endpoint that the VisiBroker ORB tries to connect to. Therefore, if multiple connection attempts are made, the elapsed time will be a multiple of the configured timeout. The default value of
0 sets the timeout value to that of the operating system default timeout.
The RelativeRequestTimeoutPolicy specifies the maximum time that a client is to block waiting to send an operation request. If the request times out,
CORBA::TIMEOUT exception is raised.
The RelativeRoundtripTimeoutPolicy specifies the relative amount of time for which a Request or its corresponding Reply may be delivered. If a response has not yet been delivered after this amount of time, the Request is canceled. Also, if a Request had already been delivered and a Reply is returned from the target, the Reply is discarded after this amount of time. This policy applies to both synchronous and asynchronous invocations. Assuming the request completes within the specified timeout, the Reply will never be discarded due to timeout. The timeout value is specified in 100s of nanoseconds.This policy is also effective in the initial establishment of a connection.
The SyncScopePolicy defines the level of synchronization for a request with respect to the target. Values of type
SyncScope are used in conjunction with a
SyncScopePolicy to control the behavior of one-way operations.