Issue 1854: Inactive thrown by certain operations (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: throughout the specification certain operations (e.g., create_subtransaction) can throw Inactive if the current transaction has been "prepared". Should this not be "terminated" to allow for the transaction having rolledback, or should a different exception (e.g., InvalidTransaction) be thrown then? Resolution: resolved, see below Revised Text: Text for when create_subtransaction can throw Inactive should be changed to use "terminating, or has already been terminated" instead of "prepared" to allow for the transaction having rolledback. Also, register_subtran_aware should be changed to use "terminating, or has already been terminated" instead of simply "has already been terminated". Revised Text: Change section 10.3.5, create_subtransaction (first paragraph) from: "A new subtransaction is created whose parent is the transaction associated with the target object. The Inactive exception is raised if the target transaction has already been prepared." to: "A new subtransaction is created whose parent is the transaction associated with the target object. The Inactive exception is raised if the target transaction is terminating, or has already been terminated." register_subtran_aware (third paragraph) from: "The NotSubtransaction exception is raised if the current transaction is not a subtransaction. The Inactive exception is raised if the subtransaction (or any ancestor) has already been terminated. The standard exception TRANSACTION_ROLLEDBACK may be raised if the subtransaction (or any ancestor) has been marked rollback only." to: "The NotSubtransaction exception is raised if the current transaction is not a subtransaction. The Inactive exception is raised if the subtransaction (or any ancestor) is terminating, or has already been terminated. The standard exception TRANSACTION_ROLLEDBACK may be raised if the subtransaction (or any ancestor) has been marked rollback only." Actions taken: August 24, 1998: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Return-Path: Date: Mon, 24 Aug 1998 12:05:57 +0100 From: Mark Little Organization: Newcastle University To: issues@omg.org, ots-rtf@omg.org Subject: further issues for OTS RTF Here are some more issues which I've come across while implementing the OTS. In no particular order: (vii) throughout the specification certain operations (e.g., create_subtransaction) can throw Inactive if the current transaction has been "prepared". Should this not be "terminated" to allow for the transaction having rolledback, or should a different exception (e.g., InvalidTransaction) be thrown then? All the best, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: "Mark Little" To: "Blake Biesecker" , References: Subject: Re: Issue 1854 Date: Tue, 21 Dec 1999 09:48:08 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: MKk!!3(md9p?Xd9^#@!! ----- Original Message ----- > Correct me if I'm mistaken, but this seems to be about whether > the sender of the messages that throw Inactive (listed below) Yes. > need more information than the Inactive provides. It seems > that if Inactive is thrown that get_status can be used to > get more detail if necessary. So, any change would be about > attempting to optimize getting the tx status information > in cases where Inactive is sent in the current spec. > > Or, is it this issue about whether Inactive is the appropriate > exception to raise in all cases it is currently thrown? > > I'm not sure exactly what this issue is getting at. Mark, can > you provide more detail about what you were hoping to get > changed or clarified by opening this issue? Yes, it was purely as a way of giving the user more information immediately. The issue tends to come about when you have a multi-threaded transaction which is not implementing fully-checked transactions (not mandates by the specification), and allows different threads to terminate a transaction. One thread commits it just before another tries to abort it, say (or even commit it). Information that the transaction has already been (or is already being) committed may be useful for the second thread to know about immediately. My point about this issue was simply that certain exceptions are either overloaded in their meaning within a single method or that the text describing why a specific exception may be thrown does not cover all possible cases (the create_subtransaction is a case in point: this could be fixed by changing "prepared" to "terminated" in the text.) Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 27 Mar 2000 13:24:02 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Re: Issue 1854 Message-ID: <20000327132401.B7845@gemstone.com> References: <03ac01bf4b98$7d139210$6e96f080@ncl.ac.uk> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <03ac01bf4b98$7d139210$6e96f080@ncl.ac.uk>; from M.C.Little@ncl.ac.uk on Tue, Dec 21, 1999 at 09:48:08AM -0000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: +OUd9,6n!!AF6!!Fm'!! Are there objections to changing "prepared" to "terminated" in the places Mark suggests below? If not, we can make an official proposal, but I'd like to discuss objections first. Blake On Tue, Dec 21, 1999 at 09:48:08AM -0000, Mark Little wrote: > > ----- Original Message ----- > > > Correct me if I'm mistaken, but this seems to be about whether > > the sender of the messages that throw Inactive (listed below) > > Yes. > > > need more information than the Inactive provides. It seems > > that if Inactive is thrown that get_status can be used to > > get more detail if necessary. So, any change would be about > > attempting to optimize getting the tx status information > > in cases where Inactive is sent in the current spec. > > > > Or, is it this issue about whether Inactive is the appropriate > > exception to raise in all cases it is currently thrown? > > > > I'm not sure exactly what this issue is getting at. Mark, can > > you provide more detail about what you were hoping to get > > changed or clarified by opening this issue? > > Yes, it was purely as a way of giving the user more information > immediately. > The issue tends to come about when you have a multi-threaded > transaction > which is not implementing fully-checked transactions (not mandates > by the > specification), and allows different threads to terminate a > transaction. One > thread commits it just before another tries to abort it, say (or > even commit > it). Information that the transaction has already been (or is > already being) > committed may be useful for the second thread to know about > immediately. > > My point about this issue was simply that certain exceptions are > either > overloaded in their meaning within a single method or that the text > describing why a specific exception may be thrown does not cover all > possible cases (the create_subtransaction is a case in point: this > could be > fixed by changing "prepared" to "terminated" in the text.) > > Mark. > > > ----------------------------------------------------------------------- > SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems > Research. > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > POST : Department of Computing Science, University of Newcastle > upon > Tyne, UK, NE1 7RU > EMAIL : M.C.Little@newcastle.ac.uk > > > Date: Tue, 18 Apr 2000 08:52:26 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: [blakeb@gemstone.com: Re: Issue 1854] Message-ID: <20000418085226.F18406@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: d<(!!^,]!!YGW!!jLSd9 I'm giving everyone another chance to lodge objections against this proposed change. I'll interpret silence as a go ahead to add this to the next vote. Blake ----- Forwarded message from Blake Biesecker ----- Date: Mon, 27 Mar 2000 13:24:02 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Re: Issue 1854 X-Mailer: Mutt 1.0pre4i In-Reply-To: <03ac01bf4b98$7d139210$6e96f080@ncl.ac.uk>; from M.C.Little@ncl.ac.uk on Tue, Dec 21, 1999 at 09:48:08AM -0000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Are there objections to changing "prepared" to "terminated" in the places Mark suggests below? If not, we can make an official proposal, but I'd like to discuss objections first. Blake On Tue, Dec 21, 1999 at 09:48:08AM -0000, Mark Little wrote: > > ----- Original Message ----- > > > Correct me if I'm mistaken, but this seems to be about whether > > the sender of the messages that throw Inactive (listed below) > > Yes. > > > need more information than the Inactive provides. It seems > > that if Inactive is thrown that get_status can be used to > > get more detail if necessary. So, any change would be about > > attempting to optimize getting the tx status information > > in cases where Inactive is sent in the current spec. > > > > Or, is it this issue about whether Inactive is the appropriate > > exception to raise in all cases it is currently thrown? > > > > I'm not sure exactly what this issue is getting at. Mark, can > > you provide more detail about what you were hoping to get > > changed or clarified by opening this issue? > > Yes, it was purely as a way of giving the user more information immediately. > The issue tends to come about when you have a multi-threaded transaction > which is not implementing fully-checked transactions (not mandates by the > specification), and allows different threads to terminate a transaction. One > thread commits it just before another tries to abort it, say (or even commit > it). Information that the transaction has already been (or is already being) > committed may be useful for the second thread to know about immediately. > > My point about this issue was simply that certain exceptions are either > overloaded in their meaning within a single method or that the text > describing why a specific exception may be thrown does not cover all > possible cases (the create_subtransaction is a case in point: this could be > fixed by changing "prepared" to "terminated" in the text.) > > Mark. > > ----------------------------------------------------------------------- > SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > POST : Department of Computing Science, University of Newcastle upon > Tyne, UK, NE1 7RU > EMAIL : M.C.Little@newcastle.ac.uk > > > ----- End forwarded message ----- From: "Mark Little" To: "Malik Saheb" , "Blake Biesecker" Cc: , "Malik SAHEB" References: <20000512155617.A10227@gemstone.com> <39242472.A3A9E45E@inria.fr> Subject: Re: Vote 2 for the OTS RTF ending December 31, 2000 - final version Date: Fri, 19 May 2000 08:52:43 +0100 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ODZ!!l,1!!]e[!!"[7e9 ----- Original Message ----- > > Issue 1854: Inactive thrown by certain operations > > Yes. > But We suggest to replace in the text: "has already been terminated" >by "is terminating". Since I wrote the text I came to roughly the same conclusion. However, "is terminating, or has already been terminated" would be better. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Fri, 19 May 2000 08:55:43 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 1854 Message-ID: <20000519085543.A16643@gemstone.com> References: <20000512155617.A10227@gemstone.com> <39242472.A3A9E45E@inria.fr> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <39242472.A3A9E45E@inria.fr>; from Malik.Saheb@inria.fr on Thu, May 18, 2000 at 07:12:19PM +0200 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: )#-e9I3R!!f@0!!XH>e9 > > > > > Issue 1854: Inactive thrown by certain operations > > Yes. > But We suggest to replace in the text: "has already been terminated" by "is terminating". > By the way We are wondering if the same ambiguity is also applied for the > Coordinator::register_resource operation. > I think it is intentional with Coordinator::register_resource. (It can get tricky to implement an OTS if you allow resources to be registered while voting is going on or while commits are being sent to resources.) Coordinator::register_subtran_aware, howver, contains this text: The Inactive exception is raised if the subtransaction (or any ancestor) has already been terminated. Should we also change this to use Mark's suggested text for create_subtransaction: "is terminating, or has already been terminated"? Blake