Issue 1851: Timeouts (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: the specification talks about timeouts for top-level transactions, and implies that there are no timeouts associated with subtransactions. Maybe we could make this explicit. (And therefore that the timeout field in the propagation context is for the top-level transaction, which is not necessarily the "current" transaction). Resolution: Make it clearer in the OTS specification that timeouts in the propagation context are for top-level Revised Text: Page 10-20, set_timeout: extend the sentence "If the parameter has a non-zero value n, then top-level transactions created by subsequent invocations of begin will be subject to being rolled back if they do not complete before n seconds after their creation." to read: "If the parameter has a non-zero value n, then top-level transactions created by subsequent invocations of begin will be subject to being rolled back if they do not complete before n seconds after their creation; nested transactions are not subject to such time-outs and will only be rolled back automatically if their enclosing top-level transaction is rolled back." Page 10-63, timeout: modify "transaction" in the sentence to "hierarchy's top-level transaction". 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: (iv) the specification talks about timeouts for top-level transactions, and implies that there are no timeouts associated with subtransactions. Maybe we could make this explicit. (And therefore that the timeout field in the propagation context is for the top-level transaction, which is not necessarily the "current" transaction). From: "Mark Little" To: "Blake Biesecker" , References: Subject: Re: Issue 1851 Date: Wed, 22 Dec 1999 09:52:05 -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: i8g!!nEVd9Z6k!!TL2e9 ----- Original Message ----- From: Blake Biesecker To: Sent: Wednesday, December 22, 1999 2:00 AM Subject: Issue 1851 > It makes sense to me that the top-level transaction should > control when a transaction times out. > > Mark, did you have particular changes to the spec in mind? Yes, I had some text somewhere. I'll dig it out and send it (probably after Christmas). 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" Cc: "OTS Revision Task Force" References: <05d901bf4c62$3a443dc0$6e96f080@ncl.ac.uk> <20000327132020.A7845@gemstone.com> Subject: Re: Issue 1851 Date: Tue, 28 Mar 2000 09:32:33 +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: k=Rd9\D$"!M-6e9Na+e9 Here's my proposed changes for issue 1851 (essentially making it clearer that timeouts in the propagation context are for top-level transactions only): Page 10-20, set_timeout: extend the sentence "If the parameter has a non-zero value n, then top-level transactions created by subsequent invocations of begin will be subjectn to being rolled back if they do not complete before n seconds after their creation." to read: "If the parameter has a non-zero value n, then top-level transactions created by subsequent invocations of begin will be subjectn to being rolled back if they do not complete before n seconds after their creation; nested transactions are not subject to such time-outs and will only be rolled back automatically if their enclosing top-level transaction is rolled back." Page 10-63, timeout: modify "transaction" in the sentence to "hierarchy's top-level transaction". Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Architect (Transactions), Arjuna Solutions PHONE : +44 191 222 8066, FAX : +44 191 222 8232 EMAIL : mark@arjuna.com Date: Tue, 28 Mar 2000 11:12:40 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Re: Issue 1851 Message-ID: <20000328111239.A13707@gemstone.com> References: <05d901bf4c62$3a443dc0$6e96f080@ncl.ac.uk> <20000327132020.A7845@gemstone.com> <073e01bf9890$2a22cea0$6e96f080@ncl.ac.uk> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <073e01bf9890$2a22cea0$6e96f080@ncl.ac.uk>; from M.C.Little@ncl.ac.uk on Tue, Mar 28, 2000 at 09:32:33AM +0100 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: @ON!!]OUd9VC'!!0Q(!! Please review Mark's proposal below. I am planning on adding this to the next vote in April, so please raise objections now. Blake On Tue, Mar 28, 2000 at 09:32:33AM +0100, Mark Little wrote: > Here's my proposed changes for issue 1851 (essentially making it > clearer > that timeouts in the propagation context are for top-level > transactions > only): > > Page 10-20, set_timeout: extend the sentence "If the parameter has a > non-zero value n, then top-level transactions created by subsequent > invocations of begin will be subjectn to being rolled back if they > do not > complete before n seconds after their creation." > > to read: > > "If the parameter has a non-zero value n, then top-level > transactions > created by subsequent invocations of begin will be subject to being > rolled > back if they do not complete before n seconds after their creation; > nested > transactions are not subject to such time-outs and will only be > rolled back > automatically if their enclosing top-level transaction is rolled > back." > > Page 10-63, timeout: modify "transaction" in the sentence to > "hierarchy's > top-level transaction". > > Mark. > > > ----------------------------------------------------------------------- > SENDER : Dr. Mark Little, Architect (Transactions), Arjuna Solutions > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > EMAIL : mark@arjuna.com > >