-
Key: CORBA3-11
-
Legacy Issue Number: 3599
-
Status: closed
-
Source: Floorboard Software ( Jonathan Biggar)
-
Summary:
I set out reading ptc/2000-04-05 to answer a question: how could a
client interceptor for the OTS implement the proper behavior for the DII
get_response or get_next_response operations that require the
WrongTransaction to be raised if the current thread is not properly
associated with the same transaction as the request.I wasn't able to answer this question authoritatively, because there is
nothing in the Portable Interceptors Chapter that indicates the proper
time sequencing of when the client side request interceptor operations
are invoked in relation to the use of the DII (or the AMI_ messaging
interfaces either.)By inference, it appears to me that the only way to allow an OTS client
{reply,exception,other}
request interceptor to exhibit the proper semantics is for the ORB to
not make calls to receive_when the response is
received from the protocol stack, but instead to make them when
get_response or get_next_response is called by the application.This paragraph in 21.3.7.2:
"Asynchronous requests are simply two separate requests. The first
request receives no reply. The second receives a normal reply. So the
normal (no exceptions) flow is: first request - send_request followed by
receive_other; second request - send_request followed by receive_reply."is also not particularly useful, since it doesn't give any indication
how the interceptor can distinguish the "first request" from the "second
request".So, to sum up, the PI chapter needs explicit information showing the
time sequencing of when the request interceptor operations are invoked
in relationship to a static call, a DII call, and AMI_ calls. -
Reported: CPP 1.1 — Tue, 9 May 2000 04:00 GMT
-
Disposition: Resolved — CORBA 3.0.2
-
Disposition Summary:
see above
-
Updated: Fri, 6 Mar 2015 20:58 GMT
CORBA3 — Detail lacking in when request interceptors are called
- Key: CORBA3-11
- OMG Task Force: Core 2002 RTF