Issue 4169: Avoiding RSC/TSC copy on server side (corba-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: During the interceptor FTF we changed the server-side threading requirements such that all server-side points run in the same thread as the ServantManager and servant except receive_request_service_contexts. We attempted to update 21.4.4.4 "Request Scope vs Thread Scope" accordingly but knew we screwed the picture and wording up. So we punted to the RTF. The main problem with the current wording is that is forces a copy of of TSC/RSC before the servant manager and then receive_request are called. This is necessary because 21.4.4.5 item 5 says: "The receive_request points may modify the RSC, but this no longer affects the TSC." The only way to make RSC identical to TSC in receive_request with respect to reading but also have them be independent with respect to writing is to make a copy (which could be optimized to copy-on-write, but why?). I suggest we just state they are equivalent after receive_request_service_contexts. Here is a proposed revision to ptc/00-08-06 along these lines. Comments? Harold 21.4.4.4 Request Scope vs Thread Scope ... On the server-side, the request scope PICurrent is attached to the ServerRequestInfo and follows the request processing. It is logically equivalent to the thread scope PICurrent after the list of receive_request_service_contexts interception points are processed. 21.4.4.5 Flow of PICurrent between Scopes 5. The ORB logically makes the RSC equivalent to the server-side TSC after the receive_request_service_contexts points are processed and before the servant manager is called. This TSC is within the context for both the receive_request points, the invocation of the servant manager, and the invocation of the target operation. The receive_request points are called. These points have access to the RSC. Modifying the RSC at this point makes corresponding modifications on the TSC. Since these points execute in the same thread as the target operation invocation, these points may modify the server-side TSC which makes corresponding modifications on the RSC. 6. After the receive_request points are called, control transfers to the server threads which may also read and write this server-side TSC. Any modifications to the TSC makes corresponding modifications on the RSC. 7. <No change> 8. <DELETE THIS ITEM> 9. The send interception points have access to the RSC (and the equivalent TSC) from which they may populate the reply service context list. After the invocation result is sent back to the client, the server-side RSC is logically destroyed. ... The picture would also need updating, but let's agree on wording first. Resolution: Revised Text: Actions taken: January 23, 2001: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== Date: Mon, 22 Jan 2001 14:45:40 -0800 (PST) Message-Id: <200101222245.OAA18112@shorter.eng.sun.com> From: Harold Carr To: interceptors-rtf@omg.org Subject: Avoiding RSC/TSC copy on server side Content-Type: text X-UIDL: ,\2e99"I!!h/$e9NKk!! (Juergen, please make this an interceptors-ftf issue.) During the interceptor FTF we changed the server-side threading requirements such that all server-side points run in the same thread as the ServantManager and servant except receive_request_service_contexts. We attempted to update 21.4.4.4 "Request Scope vs Thread Scope" accordingly but knew we screwed the picture and wording up. So we punted to the RTF. The main problem with the current wording is that is forces a copy of of TSC/RSC before the servant manager and then receive_request are called. This is necessary because 21.4.4.5 item 5 says: "The receive_request points may modify the RSC, but this no longer affects the TSC." The only way to make RSC identical to TSC in receive_request with respect to reading but also have them be independent with respect to writing is to make a copy (which could be optimized to copy-on-write, but why?). I suggest we just state they are equivalent after receive_request_service_contexts. Here is a proposed revision to ptc/00-08-06 along these lines. Comments? Harold 21.4.4.4 Request Scope vs Thread Scope ... On the server-side, the request scope PICurrent is attached to the ServerRequestInfo and follows the request processing. It is logically equivalent to the thread scope PICurrent after the list of receive_request_service_contexts interception points are processed. 21.4.4.5 Flow of PICurrent between Scopes 5. The ORB logically makes the RSC equivalent to the server-side TSC after the receive_request_service_contexts points are processed and before the servant manager is called. This TSC is within the context for both the receive_request points, the invocation of the servant manager, and the invocation of the target operation. The receive_request points are called. These points have access to the RSC. Modifying the RSC at this point makes corresponding modifications on the TSC. Since these points execute in the same thread as the target operation invocation, these points may modify the server-side TSC which makes corresponding modifications on the RSC. 6. After the receive_request points are called, control transfers to the server threads which may also read and write this server-side TSC. Any modifications to the TSC makes corresponding modifications on the RSC. 7. 8. 9. The send interception points have access to the RSC (and the equivalent TSC) from which they may populate the reply service context list. After the invocation result is sent back to the client, the server-side RSC is logically destroyed. ... The picture would also need updating, but let's agree on wording first. Date: Wed, 27 Nov 2002 13:28:53 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: CORBA Core RTF Subject: Discussion of sense of RTF issues so far So far we have voted on 4 sense of RTF issues. Here is a little update on what follows from those: 1. R1: Issues dealing with making ORB available to POA, PIs and Access to ValueFactory from PI. related issues: Issue 3403: PI needs the ORB to be available in IDL (Interceptors) Issue 3772: ORB accessor on POA? Issue 3793: No way to register value factory from ORB initializer (Interceptors) and also 3322. Status: We have been slowly putting together a concrete resolution. It is almost ready to go and should appear in vote 10 or 11. 2. R2 Regarding how to resolve issue 2772 Related Issue 2772 Status: It looks like the general feeling was that 2772 should be fixed as suggested in R2. We are awaiting a concrete draft resolution from Jon Biggar. As soon as it is available we will put it to vote. 3. R3: On the matter of how to resolve Issue 3097. Status: There is considerable reluctance on part of the voters to create a new version of GIOP to solve this problem, even though R3 did pass by a thin margin. But the fact that No's + Abstains outnumber Yesses by a significant margin should give us significant pause before we proceed down the path proposed in R3. We need to decide how to handle this one. Choices are leave it open (least desirable) or close with documentation of the problem in the specification. 4. R4: On the matter of how to resolve Issue 4169. Status: This one passed decisively. Jon had some objections that can probably be mitigated with some thought. It is upto Harold to come up with a complete draft resolution for this, in consultation with Jon. As soon as the draft is available we will put it to vote.