Issue 2349: Synchronization issue? (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Synchronizations which are registered with a top-level transaction are only informed when the transaction commits (at the start and end of the 2-phase protocol). The intention is that they can then make any transient data available to the appropriate resource. Is there not a requirement (or wouldn"t it be a good idea anyway) that they should be informed if the transaction simply rolls back (i.e., rollback is called on the Coordinator rather than commit), so that they can remove transient data, do garbage collection etc? Resolution: The resolution for this issue is to change the OTS specification so that it is clear that only the a Revised Text: Actions taken: January 27, 1999: received issue January 9, 2001: closed issue Discussion: Descriptions of the changes made to the OTS specification to resolve this issue: On page 10-32, section 10.3.8, the first paragraph should be change from: "The Transaction Service provides a synchronization protocol ..., to be notified before the start of the two-phase commitment protocol, and after its completion." to: "The Transaction Service provides a synchronization protocol ..., to be notified before the start of the two-phase commitment protocol, and after its completion. If the transaction is instructed to roll back rather than be committed, the object will only be notified after rollback completes." The the text marked with the header after_completion should be changed from: "This operation is invoked after all commit or rollback responses have been received by this coordinator. The current status of the transaction (as determined by a get_status on the Coordinator) is provided as input. Only standard exceptions may be raised and they have no effect on the outcome of the commitment process." to: "Regardless of how the transaction was originally instructed to terminate, this operation is invoked after all commit or rollback responses have been received by this coordinator. The current status of the transaction (as determined by a get_status on the Coordinator) is provided as input. Only standard exceptions may be raised and they have no effect on the outcome of the transaction termination." End of Annotations:===== Sender: nmcl@ncl.ac.uk Date: Wed, 27 Jan 1999 14:45:47 +0000 From: Mark Little Organization: Newcastle University To: issues@omg.org Subject: Synchronization issue? Synchronizations which are registered with a top-level transaction are only informed when the transaction commits (at the start and end of the 2-phase protocol). The intention is that they can then make any transient data available to the appropriate resource. Is there not a requirement (or wouldn't it be a good idea anyway) that they should be informed if the transaction simply rolls back (i.e., rollback is called on the Coordinator rather than commit), so that they can remove transient data, do garbage collection etc? 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 Sender: sedillot@bizet.inria.fr Date: Mon, 01 Feb 1999 17:47:04 +0000 From: Simone Sedillot Organization: INRIA - Rocquencourt To: Juergen Boldt CC: issues@emerald.omg.org, ots-rtf@emerald.omg.org Subject: Re: issue 2349 -- OTS RTF Issue (my guess) References: <3.0.32.19990127123228.00c57b7c@emerald.omg.org> Juergen Boldt wrote: > > This is issue # 2349 > > Synchronization issue? > > Synchronizations which are registered with a top-level transaction > are > only informed when the transaction commits (at the start and end of > the > 2-phase protocol). The intention is that they can then make any > transient data available to the appropriate resource. Is there not a > requirement (or wouldn't it be a good idea anyway) that they should > be > informed if the transaction simply rolls back (i.e., rollback is > called > on the Coordinator rather than commit), so that they can remove > transient data, do garbage collection etc? I agree since i do not see other source than timeout if your suggestion is not taken into account. simone > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-508-820 4300 ext. 132 > Framingham Corporate Center Fax: +1-508-820 4303 > 492 Old Connecticut Path Email: juergen@omg.org > Framingham, MA 01701 > > ================================================================ -- ********************************************************************** Simone Sedillot adresse: TEL: 33 (0)1 39 63 52 86 INRIA Domaine de Voluceau FAX: 33 (0)1 39 63 50 34 ROCQUENCOURT, B.P. 105 EMAIL: simone.sedillot@inria.fr 78153 LE CHESNAY CEDEX FRANCE ********************************************************************** From: blakeb@gemstone.com (Blake Biesecker) Subject: issue 2349 - OTS issue To: ots-rtf@omg.org, issues@omg.org Date: Tue, 14 Sep 1999 11:17:59 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII > This is issue # 2349 > > Synchronization issue? > > Synchronizations which are registered with a top-level transaction are > only informed when the transaction commits (at the start and end of the > 2-phase protocol). The intention is that they can then make any > transient data available to the appropriate resource. Is there not a > requirement (or wouldn't it be a good idea anyway) that they should be > informed if the transaction simply rolls back (i.e., rollback is called > on the Coordinator rather than commit), so that they can remove > transient data, do garbage collection etc? > I agree that the OTS spec is not very clear on this issue. I see three possible ways of handling Synchronization calls with an explicit rollback: 1) Do not send either before_completion or after_completion 2) Only send after_completion (as in the EJB 1.1 spec) 3) Send both before_completion and after_completion I agree with Dr. Mark Little that not sending either of the callbacks (1) can cause problems since a registered Synchronization may never be informed that the transaction has completed. Sending both (3) can also cause problems since it can be expensive to determine if a transaction has been explicitly rolled back from inside the before_completion. If it is not determined if the transaction is being rolled back, unnecessary work will most likely get done. One fix to the OTS spec that might make this situation better is adding a status argument to before_completion like in after_completion. Only sending after_completion (2) could also achieve the same results, but would require a change in the the spec as well. I'd be curious if others feel that the spec should be changed to clarify this issue, but for those of us with implementations based on the current OTS 1.1 spec, the only two options that can be done without a spec change are 1 or 3 (w/o the added argument to before_completion). Clarification from the OMG and/or the spec writers about which option was intended would be very helpful. Blake Biesecker GemStone Systems, Inc. ----- End forwarded message ----- From: "Mark Little" To: "Blake Biesecker" Cc: "OTS Revision Task Force" References: <05d901bf4c62$3a443dc0$6e96f080@ncl.ac.uk> <20000208141544.A341@gemstone.com> Subject: Issue 2349 Date: Fri, 11 Feb 2000 16:14:19 -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: (^~e91_5!!VNhd9k(I!! ----- Original Message ----- > Issue 2349 > Everyone present agreed that we should only send > after_completion > on a rollback. Mark Little agreed to craft a proposal to change > the spec since this was his issue. I suggest changing the text associated with the Synchronization issue along the following lines (with reference to page 10-32): "The Transaction Service provides a synchronization protocol ..., to be notified before the start of the two-phase commitment protocol, and after its completion." to "The Transaction Service provides a synchronization protocol ..., to be notified before the start of the two-phase commitment protocol, and after its completion. If the transaction is instructed to roll back rather than be committed, the object will only be notified after rollback completes." And slightly change the text associated with after_completion from: "Only standard exceptions may be raised and they have no effect on the outcome of the commitment process." to "Only standard exceptions may be raised and they have no effect on the outcome of the transaction termination." There's another possible modification to the text that I'm not so hung up about, but may be an idea to add just to improve clarification. It would be to change: "This operation is invoked after all commit or rollback responses have been received by this coordinator." to "Regardless of how the transaction was originally instructed to terminate, this operation is invoked after all commit or rollback responses have been received by this coordinator." 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