Issue 3748: avoiding the register_resource round trip (ots-rtf) Source: Hewlett-Packard (Dr. Peter Furniss, peter(at)arjuna.com) Nature: Uncategorized Issue Severity: Summary: > One possible use for the implementation data would be to avoid the > additional round-trip of register_resource from an interposing > sub-coordinator. This involves putting the subordinate reference (as a > Resource) in the context on the response. However, that is not enough > because the RecoveryCoordinator reference from the superior (usually > returned on register_resource) is unique to the Resource. However, if it is > possible for the superior to pre-construct a RecoveryCoordinator reference, > this can be put in the context on the request. (Obviously, not all > implementations will be able to do the pre-construction, but some will, and, > when working homogeneously, gain the advantages of interposition without the > cost of the extra round trip). > > The RecovCoordinate reference would only be a "potential" reference, > becoming real if and only if the response context included a Resource > reference - receipt of that Resource reference requiring an immediate > (locally-handled) registration. > > Two possible changes arise: > > 1) If this is done, it is vital that an implementation that does not > understand this discards the implementation-specific data (contra the > resolution of 3593) > > 2) Alternatively this could be done in a separate, defined service context. > The semantics can be tied down precisely and allow avoidance of the > round-trip even on interoperation. Resolution: Revised Text: Actions taken: July 18, 2000: received issue Discussion: End of Annotations:===== rom: "Peter Furniss" To: "OTS-RTF" Subject: OTS new issue - avoiding the register_resource round trip Date: Tue, 18 Jul 2000 18:42:25 +0100 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: &0V!!Sp^!!k%Md9gNC!! Now the dust is settling on 3425, I'll raise something that came out of other discussions in Oslo. It derives from conversation on issue 3593, but goes wider. One possible use for the implementation data would be to avoid the additional round-trip of register_resource from an interposing sub-coordinator. This involves putting the subordinate reference (as a Resource) in the context on the response. However, that is not enough because the RecoveryCoordinator reference from the superior (usually returned on register_resource) is unique to the Resource. However, if it is possible for the superior to pre-construct a RecoveryCoordinator reference, this can be put in the context on the request. (Obviously, not all implementations will be able to do the pre-construction, but some will, and, when working homogeneously, gain the advantages of interposition without the cost of the extra round trip). The RecovCoordinate reference would only be a "potential" reference, becoming real if and only if the response context included a Resource reference - receipt of that Resource reference requiring an immediate (locally-handled) registration. Two possible changes arise: 1) If this is done, it is vital that an implementation that does not understand this discards the implementation-specific data (contra the resolution of 3593) 2) Alternatively this could be done in a separate, defined service context. The semantics can be tied down precisely and allow avoidance of the round-trip even on interoperation. And, relatedly: It does not seem to be strictly necessary for the RecoveryCoordinator reference to be unique for each branch. The only operation in the interface is replay_completion, which identifies the branch anyway by carrying the Resource reference of the bottom end. Although some implementations may find it easier to have different RecoveryCoordinator references for each branch, I suspect others would be easier if all branches used the same RecovCoord. (Certainly the trick above becomes easier) (It would also be possible to use the context mechanism to register one non-subcoordinator resource, but only one, which might be tricky) Peter Furniss (Bluestone / Arjuna) peter@arjuna.com Date: Wed, 1 Nov 2000 17:38:43 -0800 From: Blake Biesecker To: peter@arjuna.com Cc: ots-rtf@.omg.org Subject: Re: issue 3748 - avoiding the register_resource round trip Message-ID: <20001101173843.F22453@gemstone.com> References: <4.2.0.58.20000718150040.00a15bc0@emerald.omg.org> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <4.2.0.58.20000718150040.00a15bc0@emerald.omg.org>; from juergen@omg.org on Tue, Jul 18, 2000 at 03:01:52PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: EAX!!T)"e9YhMe9Gkg!! Peter, Did you want to propose text changes to address your this issue? Blake On Tue, Jul 18, 2000 at 03:01:52PM -0400, Juergen Boldt wrote: > This is issue # 3748 ("Peter Furniss" ) > > avoiding the register_resource round trip > > One possible use for the implementation data would be to avoid the > additional round-trip of register_resource from an interposing > sub-coordinator. This involves putting the subordinate reference (as a > Resource) in the context on the response. However, that is not enough > because the RecoveryCoordinator reference from the superior (usually > returned on register_resource) is unique to the Resource. However, if it is > possible for the superior to pre-construct a RecoveryCoordinator reference, > this can be put in the context on the request. (Obviously, not all > implementations will be able to do the pre-construction, but some will, and, > when working homogeneously, gain the advantages of interposition without the > cost of the extra round trip). > > The RecovCoordinate reference would only be a "potential" reference, > becoming real if and only if the response context included a Resource > reference - receipt of that Resource reference requiring an immediate > (locally-handled) registration. > > Two possible changes arise: > > 1) If this is done, it is vital that an implementation that does not > understand this discards the implementation-specific data (contra the > resolution of 3593) > > 2) Alternatively this could be done in a separate, defined service context. > The semantics can be tied down precisely and allow avoidance of the > round-trip even on interoperation. > ================================================================ > > 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 > > > > ================================================================