Subject: Detecting Recursion in Other Interceptors To: interceptors-rtf@omg.org Cc: "Ian Robinson" , Russell_Butek/Austin/IBM%IBMGB , Leo_Uzcategui/Austin/IBM%IBMGB X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tim Baldwin" Date: Tue, 4 Sep 2001 12:27:49 +0100 X-MIMETrack: Serialize by Router on d06ml004/06/M/IBM(Release 5.0.8 |June 18, 2001) at 04/09/2001 12:24:08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: !eLe97?8e9gKh!!g43e9 We have identified a requirement where the interceptors for one service need to be able to detect recursive invocations made by some other interceptor during the processing of a request. As far as we have been able to determine there is no way to achieve this using the Request-scope/Thread-scope Current mechanism described in the spec. It is probably easiest to explain this using a specific example. Start with some form of "transaction" service that registers client-side interceptors so it can detect all new request invocations and add service contexts that perform some form of "begin transaction" processing at the server. This transaction service must only perform this "begin transaction" once per application-level request, so it allocates a PICurrent slot and performs the processing described in section 21.4.4.2 to ensure that any recursive calls it makes itself will form part of the same transaction and not begin a new one. However a problem now occurs if we introduce some other service, say a "security" service that has its own interceptors registered. The order in which these two service's interceptors run can affect what happens, but since interceptor ordering is undefined assume that the security interceptor runs first. An application makes a request on its own thread A. The send_request interceptors start to run on thread B and the security interceptor runs first, at this point both the RSC and TSC slots for the transaction service are empty. The security interceptor makes a recursive request so the send_request interceptors run again on a new thread C. The security interceptor runs again and this time doesn't recurse so the transaction interceptor now runs on thread C. At this point it finds its RSC slot empty so does a "begin transaction" and sets its TSC for thread C. We've now finished interceptors on thread C and return to thread B and invoke send_request for the transaction service. Once again it finds its RSC slot empty and will try to "begin transaction" again. Now we have a problem as we have issued two "begin transactions" for the same application request. In fact it as actually the second of those two "begin transactions" that we really want to do, as that represents the true start of the application's transaction. The first one (caused by the recursive call in the other interceptor) is at best redundant and wasteful and at worst wrong and problematic. Does anyone have any comments on this problem? Regards, Tim - - - Tim Baldwin, Java Technology Centre, IBM UK Labs, Hursley Email: Tim Baldwin/UK/IBM@IBMGB, baldwint@uk.ibm.com Tel: +44-(0)1962-815749 (Internal: 245749) X-Sender: beckwb@postel X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 05 Sep 2001 09:44:05 -0400 To: tim_baldwin@uk.ibm.com From: Bill Beckwith Subject: Re: issues 4554 -- Interceptors RTF issue Cc: interceptors-rtf@emerald.omg.org In-Reply-To: <4.3.2.7.2.20010904122803.0257cce0@emerald.omg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ;_Z!!TKTd99N4e9:am!! I've also been thinking about this issue. My initial thoughts were along the line of setting some state in PICurrent that would effect or suppress subsequent calls to (1) inceptors of the same name or (2) all interceptors. Would this work for your requirements? Bill At 12:28 PM 9/4/2001 -0400, Juergen Boldt wrote: >This is issue # 4554 Tim Baldwin" >Detecting Recursion in Other Interceptors > >We have identified a requirement where the interceptors for one service >need to be able to detect recursive invocations made by some other >interceptor during the processing of a request. As far as we have been >able to determine there is no way to achieve this using the >Request-scope/Thread-scope Current mechanism described in the spec. > >It is probably easiest to explain this using a specific example. Start >with some form of "transaction" service that registers client-side >interceptors so it can detect all new request invocations and add service >contexts that perform some form of "begin transaction" processing at the >server. This transaction service must only perform this "begin >transaction" once per application-level request, so it allocates a >PICurrent slot and performs the processing described in section 21.4.4.2 to >ensure that any recursive calls it makes itself will form part of the same >transaction and not begin a new one. > >However a problem now occurs if we introduce some other service, say a >"security" service that has its own interceptors registered. The order in >which these two service's interceptors run can affect what happens, but >since interceptor ordering is undefined assume that the security >interceptor runs first. > >An application makes a request on its own thread A. The send_request >interceptors start to run on thread B and the security interceptor runs >first, at this point both the RSC and TSC slots for the transaction service >are empty. The security interceptor makes a recursive request so the >send_request interceptors run again on a new thread C. The security >interceptor runs again and this time doesn't recurse so the transaction >interceptor now runs on thread C. At this point it finds its RSC slot >empty so does a "begin transaction" and sets its TSC for thread C. We've >now finished interceptors on thread C and return to thread B and invoke >send_request for the transaction service. Once again it finds its RSC slot >empty and will try to "begin transaction" again. Now we have a problem as >we have issued two "begin transactions" for the same application request. > >In fact it as actually the second of those two "begin transactions" that we >really want to do, as that represents the true start of the application's >transaction. The first one (caused by the recursive call in the other >interceptor) is at best redundant and wasteful and at worst wrong and >problematic. > >Does anyone have any comments on this problem? >================================================================ > >Juergen Boldt >Senior Member of Technical Staff > >Object Management Group Tel. +1-781 444 0404 ext. 132 >250 First Avenue, Suite 201 Fax: +1-781 444 0320 >Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > >================================================================ > Reply-To: From: "Matthew Newhook" To: "Tim Baldwin" , Cc: "Ian Robinson" , "Russell_Butek/Austin/IBM%IBMGB" , "Leo_Uzcategui/Austin/IBM%IBMGB" Subject: RE: Detecting Recursion in Other Interceptors Date: Thu, 6 Sep 2001 06:49:35 -0230 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="us-ascii" X-UIDL: I@S!!4hBe9,6U!!2+'!! Hi, The idea wasn't that the order of interceptors is undefined. The idea was that exactly how the order is defined is undefined. From the spec: Each Interceptor may have a name that may be used administratively to order the lists of Interceptors. Only one Interceptor of a given name can be registered with the ORB for each Interceptor type. An Interceptor may be anonymous, ie., have an empty string as the name attribute. Any number of anonymous Interceptors may be registered with the ORB. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew.newhook@iona.com VP CORBA Development WWW: http://www.iona.com IONA Total Business Integration(tm) Phone: (709) 738-3725 > -----Original Message----- > From: Tim Baldwin [mailto:tim_baldwin@uk.ibm.com] > Sent: Tuesday, September 04, 2001 8:58 AM > To: interceptors-rtf@omg.org > Cc: Ian Robinson; Russell_Butek/Austin/IBM%IBMGB; > Leo_Uzcategui/Austin/IBM%IBMGB > Subject: Detecting Recursion in Other Interceptors > > > We have identified a requirement where the interceptors for one service > need to be able to detect recursive invocations made by some other > interceptor during the processing of a request. As far as we have been > able to determine there is no way to achieve this using the > Request-scope/Thread-scope Current mechanism described in the spec. > > It is probably easiest to explain this using a specific example. Start > with some form of "transaction" service that registers client-side > interceptors so it can detect all new request invocations and add service > contexts that perform some form of "begin transaction" processing at the > server. This transaction service must only perform this "begin > transaction" once per application-level request, so it allocates a > PICurrent slot and performs the processing described in section > 21.4.4.2 to > ensure that any recursive calls it makes itself will form part of the same > transaction and not begin a new one. > > However a problem now occurs if we introduce some other service, say a > "security" service that has its own interceptors registered. The order in > which these two service's interceptors run can affect what happens, but > since interceptor ordering is undefined assume that the security > interceptor runs first. > > An application makes a request on its own thread A. The send_request > interceptors start to run on thread B and the security interceptor runs > first, at this point both the RSC and TSC slots for the > transaction service > are empty. The security interceptor makes a recursive request so the > send_request interceptors run again on a new thread C. The security > interceptor runs again and this time doesn't recurse so the transaction > interceptor now runs on thread C. At this point it finds its RSC slot > empty so does a "begin transaction" and sets its TSC for thread C. We've > now finished interceptors on thread C and return to thread B and invoke > send_request for the transaction service. Once again it finds > its RSC slot > empty and will try to "begin transaction" again. Now we have a problem as > we have issued two "begin transactions" for the same application request. > > In fact it as actually the second of those two "begin > transactions" that we > really want to do, as that represents the true start of the application's > transaction. The first one (caused by the recursive call in the other > interceptor) is at best redundant and wasteful and at worst wrong and > problematic. > > Does anyone have any comments on this problem? > > Regards, Tim > - - - > Tim Baldwin, Java Technology Centre, IBM UK Labs, Hursley > Email: Tim Baldwin/UK/IBM@IBMGB, baldwint@uk.ibm.com > Tel: +44-(0)1962-815749 (Internal: 245749) Subject: RE: Detecting Recursion in Other Interceptors To: Cc: "Ian Robinson" , interceptors-rtf@omg.org, Leo_Uzcategui/Austin/IBM , Russell_Butek/Austin/IBM X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tim Baldwin" Date: Thu, 6 Sep 2001 15:57:18 +0100 X-MIMETrack: Serialize by Router on d06ml004/06/M/IBM(Release 5.0.8 |June 18, 2001) at 06/09/2001 15:56:39 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: TYHe9/n!e9SH#e92Q\d9 Matthew, I agree with what you are saying about interceptor ordering and it is also true that the particular problem I outlined in my original email would be solved if my "transaction" interceptor was always the first interceptor run. However I'd be very relcutant to offer this as a solution. There are several different groups writing interceptors for my ORBs and I can well imagine that they could all come up with several good reasons why they each believe they should be first! At the moment our preferred solution to this would be to provide a new operation on the ClientRequestInfo interface, ClientRequestInfo::recursion_level. This would return a value representing the true nested recursion depth of the interceptor being run. In my example the "transaction" interceptor could examine this and only do its "begin transaction" processing when it was at the top level. Regards, Tim - - - Tim Baldwin, Java Technology Centre, IBM UK Labs, Hursley Email: Tim Baldwin/UK/IBM@IBMGB, baldwint@uk.ibm.com Tel: +44-(0)1962-815749 (Internal: 245749) "Matthew Newhook" To: Tim Baldwin/UK/IBM@IBMGB, Uzcategui/Austin/IBM@ibmus Subject: RE: Detecting Recursion in Other Interceptors 06/09/2001 07:49 Please respond to matthew.newhook Hi, The idea wasn't that the order of interceptors is undefined. The idea was that exactly how the order is defined is undefined. From the spec: Each Interceptor may have a name that may be used administratively to order the lists of Interceptors. Only one Interceptor of a given name can be registered with the ORB Date: Thu, 6 Sep 2001 14:05:30 -0700 (PDT) Message-Id: <200109062105.f86L5UZ01745@ha1sca-mail1.SFBay.Sun.COM> From: Harold Carr To: interceptors-rtf@omg.org Subject: Re: issues 4554 - Interceptors RTF issue Content-Type: text X-UIDL: TR`d9,^n!!J-^d9L9T!! Hello Tim, I agree there is a problem. It can be diagrammed as: tA tB tC 1 foo.bar 2 SecCRI.sr 4 SecCRI.sr 3 x.y 5 TxCRI.sr 6 begin_tx 7 TxCRI.sr 8 begin_tx I would like to get clarification of something in your example. You say that the transcation interceptor does a begin transaction. This seems incorrect. It seems that the application code should be marking the begin and end of the transaction (which causes a Tx ID to get created and put into a TSC slot). pseudocode: TxServer = (narrow) orb.resolve_initial_references("Tx"); ... TxServer.begin(); foo.bar(); ... TxServer.end(); If that is the case then the problem goes away: tA tB tC 0 begin 1 foo.bar 2 SecCRI.sr 5 SecCRI.sr 3 Set TSC 4 x.y() 6 TxCRI.sr 7 TxCRI.sr insert TxId 8 end The security interceptor at 2 sees that its recursion RSC slot is not set so it sets it (3) and makes the out call (4). In 5 it sees the RSC slot set so does nothing. The transaction interceptor runs in 6 but does not see the TxID (since it is a new RSC for servicing x.y(). So it does nothing. The transaction interceptor at 7 sees the RSC TxId so inserts the proper service context. If the order of SecCRI and TxCRI is reversed the above still works properly. I think the model has always been that services are started and ended in applications code, not inside interceptors. That said, there is a general problem when two or more interceptors are registered and two or more of them make outcalls. I'll send out a solution for that case in a future mail. First I would like comments on the above. Cheers, Harold Date: Thu, 14 Nov 2002 13:07:06 -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-rtf@omg.org Subject: Proposed resolution for 4554 This resolution will appear in a vote in the near future unless there is serious technical objection to it. Jishnu. _______________________________________________________________________ Issue 4554: Detecting Recursion in Other Interceptors (interceptors-rtf) Click http://cgi.omg.org/issues/issue4554.txt for this issue's archive. Source: International Business Machines (Mr. Tim Baldwin, tim_baldwin@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: See archive Resolution: This issue is based on faulty premises. It states that the transaction interceptor does a begin transaction. This is not the transaction model nor the model supported by the design of Portable Interceptors. The application code is responsible for marking the begin and end of the transaction. When the begin/end is marked outside of interceptors there is no problem with recursion. Close no change. Revised Text: Actions taken: Close no change