Issue 1929: OTS timeout (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: issue about what timeout value is actually sent in the PropagationContext? If it is the timeout with which the original transaction was created, then the server-side transaction may hang around for longer than is required. Should this value not be the timeout which *remained* at the client when it made the call? Resolution: see below Revised Text: In 2.14.2.3) Transaction Service Interoperation, add the following sentence to the timeout description: This timeout is the time remaining, i.e. the timeout when the transaction was begun (or the timeout received through a transactional request, or through a Current::resume operation) less the elapsed time, in seconds Actions taken: September 3, 1998: received issue May 13, 2002: closed issue Discussion: Resolution: the timeout value sent in transaction contexts for top-level transactions is the time remaining (in seconds). End of Annotations:===== Return-Path: Sender: nmcl@newcastle.ac.uk Date: Thu, 03 Sep 1998 09:08:58 +0100 From: Mark Little Organization: Newcastle University To: issues@omg.org Subject: OTS timeout When creating a new top-level transaction it is possible to specify a timeout (in seconds). If the transaction has not completed within this timeout it will be rolledback. When a remote call is made and interposition is to be used at the server to create a subordinate coordinator, the PropagationContext which is used by recreate contains the callers transaction hierarchy and the top-level timeout. This could then be used by the server to timeout the server-side of the top-level transaction without requiring intervention by the original coordinator, i.e., if the server hasn't received a call to prepare/rollback within time T it will simply rollback. However, this then raises the issue about what timeout value is actually sent in the PropagationContext? If it is the timeout with which the original transaction was created, then the server-side transaction may hang around for longer than is required. Should this value not be the timeout which *remained* at the client when it made the call? 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: "Bernard Normier" , "OTS RTF" References: <03d001c19d50$ae1faae0$4985413f@boston.amer.iona.com> Subject: Re: Let's solve some OTS issues! Date: Wed, 16 Jan 2002 17:51:14 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ee"e9GF#!!=*~e9<0)!! A few proposals to issues I've raised in the past then: Issue 1929: the timeout value sent in transaction contexts for top-level transactions is the time remaining (in seconds). Issue 1848: update the description of register_synchronization to require SynchronizationUnavailable to be thrown if the current transaction is a subtransaction. Issue 2618: modify the paragraph on register_resource to include: "If a the resource is a Resource and the current transaction is a subtransaction, then the Resource is registered as a participant in the current transaction and indirectly with the parent if the current transaction commits and all parents up to the root transaction also commit." Issue 4343: close this issue as it is mentioned in the section on subordinate coordinator on page 10-58. I'd like to address a couple of older issues (1998) about subtransactions but this will require a revisit about what we think subtransactions are! A little late for what could be a long discussion. BTW, have we removed anonymous types from the IDL as 3762 mentions? Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250