Issue 2610: resume(), checking and transaction interoperation (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: I believe this to be a minor flaw in OTS. Problem: There is no apparent way of turning off checking in an OTS that supports it. This makes it impossible to involve an OTS-based server using implicit propagation in a transaction that is imported (bridged) into OTS from some other transaction mechanism. Resolution: Revised Text: There is no apparent way of turning off checking in an OTS that supports it. This makes it impossible to involve an OTS-based server using implicit propagation in a transaction that is imported (bridged) into OTS from some other transaction mechanism. Actions taken: April 16, 1999: received issue Discussion: End of Annotations:===== From: Peter Furniss To: "'ots-rtf@omg.org'" Subject: resume(), checking and transaction interoperation Date: Thu, 15 Apr 1999 22:57:48 +0100 X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id SAA23100 I believe this to be a minor flaw in OTS. Problem: There is no apparent way of turning off checking in an OTS that supports it. This makes it impossible to involve an OTS-based server using implicit propagation in a transaction that is imported (bridged) into OTS from some other transaction mechanism. This point was mentioned in my presentation to Orbos in Philadelphia on interoperation between MTS and OTS (see orbos/99-03-33), but would apply to any interoperation between a foreign transaction service and an OTS-based server that used implicit propagation. It will also apply where a purely OTS transaction has explicit propagation "above" implicit - e.g.. with explicit propagation at the client but implicit at the server. With interoperation, the incoming transaction identity will somehow be converted to a Control reference (using recreate or equivalent). To switch into implicit propagation, the application thread must now call Current::resume(), supplying this Control reference. Obviously the thread has not previously been associated with this Control, so if checking is supported, the resume check will fail. If checking is not supported, the resume will work (and does in our MTS-OTS bridge). Note that this is not suggesting the underlying semantic of checking is being contradicted - the application better not mislead the superior into initiating commitment until the registration is complete. But the application (actually a bridge element probably) needs to be able to tell OTS that on this occasion it knows what it is doing. Obvious possible approaches would be a variant of resume() or a checking-on/checking-off switch of some form. Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk X-Sender: ecobb@svlhome2.beasys.com Date: Fri, 16 Apr 1999 08:50:14 -0700 To: Peter Furniss , "'ots-rtf@omg.org'" From: Edward Cobb Subject: Re: resume(), checking and transaction interoperation Peter, as I believe I told you in Philadelphia, you are correct. Would you please post this to issues@omg.org so the OTS revision task force can consider fixing it? Thanks, At 10:57 PM 4/15/99 +0100, Peter Furniss wrote: >I believe this to be a minor flaw in OTS. > >Problem: There is no apparent way of turning off checking in an OTS that supports it. This makes it impossible to involve an OTS-based server using implicit propagation in a transaction that is imported (bridged) into OTS from some other transaction mechanism. > >This point was mentioned in my presentation to Orbos in Philadelphia on interoperation between MTS and OTS (see orbos/99-03-33), but would apply to any interoperation between a foreign transaction service and an OTS-based server that used implicit propagation. It will also apply where a purely OTS transaction has explicit propagation "above" implicit - e.g.. with explicit propagation at the client but implicit at the server. > >With interoperation, the incoming transaction identity will somehow be converted to a Control reference (using recreate or equivalent). To switch into implicit propagation, the application thread must now call Current::resume(), supplying this Control reference. Obviously the thread has not previously been associated with this Control, so if checking is supported, the resume check will fail. If checking is not supported, the resume will work (and does in our MTS-OTS bridge). > >Note that this is not suggesting the underlying semantic of checking is being contradicted - the application better not mislead the superior into initiating commitment until the registration is complete. But the application (actually a bridge element probably) needs to be able to tell OTS that on this occasion it knows what it is doing. > >Obvious possible approaches would be a variant of resume() or a checking-on/checking-off switch of some form. > > >Peter Furniss > >-------------------------------------- >Associate >Open-IT Limited >58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK >Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) >Email : P.Furniss@mailbox.ulcc.ac.uk > > > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8910 E-mail: ed.cobb@beasys.com From: Peter Furniss To: "'Blake Biesecker'" Cc: "ots-rtf@omg.org" Subject: RE: Issue 2610: resume(), checking and transaction interoperation Date: Wed, 9 Feb 2000 12:48:20 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id IAA11177 Content-Type: text/plain; charset="us-ascii" X-UIDL: H,@!!MINd9[9[!!EgE!! Blake Biesecker sent : > Peter, > > Since you opened this issue, are you interested in > taking ownership of it? In particular, I need a > concrete proposal that we can vote on. Ok, but discussion with others (who are on this list) since I raised the issue suggests there are aspects I hadn't originally seen, so I wouldn't want to draft text yet. But I'll open the bidding below > To the rest of the group, are there any comments > on this issue? (Discussion can help bring out > ideas for resoloving an issue ...) > Problem: There is no apparent way of turning off checking in an OTS > that supports it. This makes it impossible to involve an OTS-based > server using implicit propagation in a transaction that is imported > (bridged) into OTS from some other transaction mechanism. I over-summarised that last sentence - it is impossible to import into a checking OTS and then use implicit (and thus checkable) propagation. If the OTS does not support checking, it can be done (and was, in the TIPOTS prototype) Note that the problem also applies in a multi-tier case where the lower tiers (end-server) require implicit propagation, but for some reason the upper tier (towards the client, but in the transaction) is using explicit propagation. In either case, the need is to change the transactional context of the thread of control from (apparently) non-transactional to transactional, but for a transaction that already exists. It will not be possible to provide checking for the upper parts of the transaction precisely because the previous propagation has been invisible to the ORB and OTS - checking from here on down would be possible, though it would mean something slightly different. At present, it seems the only way to do this with OTS is to use resume(). If checking is not implemented, resume() should be quite happy to take a context that has not been on this thread before. However, it can be argued that this is an abuse of resume(), and there should be another Current operation to set the transaction context to something it has never been for this thread. This might be better than being able to turn off the checking. Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Date: Wed, 1 Nov 2000 11:41:07 -0800 From: Blake Biesecker To: Peter Furniss Cc: "ots-rtf@omg.org" Subject: Re: Issue 2610: resume(), checking and transaction interoperation Message-ID: <20001101114107.C22222@gemstone.com> References: <01BF72FE.872E95A0@B179.ds.ulcc.ac.uk> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <01BF72FE.872E95A0@B179.ds.ulcc.ac.uk>; from p.furniss@mailbox.ulcc.ac.uk on Wed, Feb 09, 2000 at 12:48:20PM -0000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 2~[!!_!O!!jA=e9HC'e9 Peter, How would you like to see this issue resolved? Blake On Wed, Feb 09, 2000 at 12:48:20PM -0000, Peter Furniss wrote: > Blake Biesecker sent : > > > Peter, > > > > Since you opened this issue, are you interested in > > taking ownership of it? In particular, I need a > > concrete proposal that we can vote on. > > Ok, but discussion with others (who are on this list) since I raised the issue suggests there are aspects I hadn't originally seen, so I wouldn't want to draft text yet. But I'll open the bidding below > > > To the rest of the group, are there any comments > > on this issue? (Discussion can help bring out > > ideas for resoloving an issue ...) > > > > Problem: There is no apparent way of turning off checking in an OTS > > that supports it. This makes it impossible to involve an OTS-based > > server using implicit propagation in a transaction that is imported > > (bridged) into OTS from some other transaction mechanism. > > I over-summarised that last sentence - it is impossible to import into a checking OTS and then use implicit (and thus checkable) propagation. If the OTS does not support checking, it can be done (and was, in the TIPOTS prototype) > > Note that the problem also applies in a multi-tier case where the lower tiers (end-server) require implicit propagation, but for some reason the upper tier (towards the client, but in the transaction) is using explicit propagation. > > In either case, the need is to change the transactional context of the thread of control from (apparently) non-transactional to transactional, but for a transaction that already exists. It will not be possible to provide checking for the upper parts of the transaction precisely because the previous propagation has been invisible to the ORB and OTS - checking from here on down would be possible, though it would mean something slightly different. > > At present, it seems the only way to do this with OTS is to use resume(). If checking is not implemented, resume() should be quite happy to take a context that has not been on this thread before. However, it can be argued that this is an abuse of resume(), and there should be another Current operation to set the transaction context to something it has never been for this thread. This might be better than being able to turn off the checking. > > > Peter Furniss > > -------------------------------------- > Associate > Open-IT Limited > 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK > Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) > Email : P.Furniss@mailbox.ulcc.ac.uk > > >