Previous | Table of Contents | Next |
22.2.2.1 typedef short SyncScope
Describes the level of synchronization for a request with respect to the target. Values of type SyncScope are used in conjunction
with a SyncScopePolicy, as described
in Section 22.2.2.2, “interface SyncScopePolicy,? on page 22-7, to control the behavior
of oneway operations. All non-negative values are reserved for use in OMG specifications. Any negative value of SyncScope
is considered a vendor extension.
• SYNC_NONE - equivalent to one allowable interpretation of CORBA oneway operations. The ORB returns control to the client (e.g., returns from the method invocation) before passing the request message to the transport protocol. The client is guaranteed not to block. Since no reply is returned from the server, no location-forwarding can be done with this level of synchronization.
• SYNC_WITH_TRANSPORT - equivalent to one allowable interpretation of CORBA oneway operations. The ORB returns control to the client only after the transport has accepted the request message. This in itself gives no guarantee that the request will be delivered, but in conjunction with knowledge of the characteristics of the transport may provide the client with a useful degree of assurance. For example, for a direct message over TCP, SYNC_WITH_TRANSPORT is not a stronger guarantee than SYNC_NONE. However, for a store-and-forward transport, this QoS provides a high level of reliability. Since no reply is returned from the server, no location-forwarding can be done with this level of synchronization.
• SYNC_WITH_TARGET - equivalent to a synchronous, non-oneway operation in CORBA. The server-side ORB shall only send the reply message after the target has completed the invoked operation. Note that any LOCATION_FORWARD reply will already have been sent prior to invoking the target and that a SYSTEM_EXCEPTION reply may be sent at anytime (depending on the semantics of the exception). Even though it was declared oneway, the operation actually has the behavior of a synchronous operation. This form of synchronization guarantees that the client knows that the target has seen and acted upon a request. As with CORBA, only with this highest level of synchronization can the OTS be used. Any operations invoked with lesser synchronization precludes the target from participating in the client’s current transaction.
• SYNC_WITH_SERVER - the server-side ORB sends a reply before invoking the target implementation. If a reply of NO_EXCEPTION is sent, any necessary location-forwarding has already occurred. Upon receipt of this reply, the client-side ORB returns control to the client application. This form of guarantee is useful where the reliability of the network is substantially lower than that of the server.
The client blocks until all location-forwarding has been completed. For a server using a POA, the reply would be sent after invoking any ServantManager, but before delivering the request to the target Servant.
22.2.2.2 interface SyncScopePolicy
This interface is a local object derived from CORBA::Policy. It is applied to oneway operations to indicate the synchronization
scope with respect to the target of that operation request. It is ignored when any non-oneway operation is invoked. This policy
is also applied when the DII is used with a flag of INV_NO_RESPONSE since the implementation of the DII is not required to
consult an interface definition to determine if an operation is declared oneway. The default value of this Policy is not defined.
Applications must explicitly set an ORB-level SyncScopePolicy to ensure portability across ORB implementations. When instances
of SyncScopePolicy are created, a value of type Messaging::SyncScope is passed to CORBA::ORB::create_policy. This policy is
only applicable as a client-side override. The client’s SyncScopePolicy is propagated within a request in the RequestHeader’s
response_flags as described in GIOP Request Header.