Issue 304: OTS v2 Synchronization (transactions) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Discussion about synchronization interface, added in latest draft of OTS spec. Should the described set of problems be addressed in current level of the spec?(/archives/issues/issue304) Resolution: Revised Text: Actions taken: October 31, 1996: received issue Discussion: End of Annotations:===== >From mail Thu Oct 31 12:17 EST 1996 Return-Path: To: transactions-wg From: "Edward Cobb" Date: 31 Oct 96 8:42:39 Subject: OTS v2 Synchronization Content-Length: 3931 There has been a fair amount of discussion about the synchronization interface added in the latest draft of the OTS specification, including some that has happened internally in IBM. I'm enclosing a note from one of our OTS developers that may be of interest. The set of problems described in this note are not addressed in the current level of the spec. I'm trying to decide if they should be. Would appreciate your feedback. Ed Cobb ---------------------- Forwarded by Edward Cobb on 10-31-96 08:40 AM --------------------------- hutchig @ winvmd.VNET 10-28-96 09:44 AM To: eecobb%stlps.VNET @ stlvm10.stl.ibm.com ("Edward Cobb ") @ SMTP, tjfreund%winvmd.VNET @ stlvm10.stl.ibm.com ("Freund Tom J ") @ SMTP cc: (bcc: Edward Cobb) Subject: OTS v2 Synchronosation From: Gordon Hutchison Tel: 245646 (+44)/(0)1962 815646 Subject: OTS v2 Synchronosation Dear Ed, Tom I have been thinking about the syncronization interface. The following in particular: 1 - We have a very strong customer requirement to be able to support multiple levels of caching (ie mote than 2 level store) 2 - Many synchronosation objects will require the pre-prepare but not be interested in the post-commit. Thus we are ham stringing our performance in such cases with a complete set of cascaded massages that are usually not wanted. 3 - Some applications need the 'depth first' behaviour requiring a separate walk of the sync tree (as they cannot gaurantee a commit/sync tree rather than a graph if the datastore is included) While many/most applications will have strict tree topologies and will perform more poorly if we do a strict depth first for just the sync objects - as currently this causes two complete extra walks of the tree. 4 - As OTS moves from an academic prototype to a real in-anger piece of business software we should place more emphasis on performance (eg 4 walks of the tree so the software will deal with all possible scenarios is less acceptable). We need: 1 - To support levels of pre-prepare 2 - To allow selection of post commit or not 3 - To allow selection of depth first/high performance I propose we try and get these into the OTS version 2 spec. One possible solution would be to have the following: register_synchronization( in synchronisation sync, in unsigned long level in sync_behavior behavior ) Where 'level' is a positive integer where messages are cascaded from higher levels prior to lower (eg 4,3,2,1,0) Where behavior means the following: enum sync_behaviour { GLOBAL_PREPREPARE, synchronize preprepare prior to any node commiting (depth first walk of sync tree) LOCAL_PREPREPARE, synchronize prior to the each local coordinator distributing prepare GLOBAL_SYNC, as in GLOBAL_PREPREPARE but with postcommit as well LOCAL_SYNC, as in LOCAL_PREPREPARE but with postcommit as well GLOBAL_POSTPREPARE, synchronize postprepare after all nodes commit (depth first walk of sync tree) LOCAL_POSTPREPARE, synchronize postprepare after all nodes commit MIXED_SYNC, preprepares are depth first, posts are optimised } I realise that this is less elegant than having the 'pure' behaviour of defaulting to GLOBAL_SYNC but it is also likely to cut the number of tree-walks required by most of our customers from 4 to 2. Do you think this is useful and could you open this out to the transactions work group? I am not worried about any of the syntax or naming specifics just the levels of caching and the performance improvements. I would be very interested in your feedback. Thanks in advance, Best regards, Gordon Hutchison hutchig@winvmd.vnet.ibm.com From mail Tue Dec 3 16:33 EST 1996 From: eecobb@us1.ibm.com X400-Originator: eecobb@us1.ibm.com X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/ADMD=IBMSMTP/C=US/;5030100002356646000002] X400-Content-Type: P2-1988 (22) To: Cc: Subject: Late breaking issues (299-304) on the transaction service sp Date: Tue, 3 Dec 1996 16:28:49 -0500 Content-Length: 2786 Classification: Prologue: Senior Technical Staff Member Member - IBM Academy of Technology Internet Address: eecobb@us1.ibm.com OR ed_cobb@vnet.ibm.com Notes Address: Edward Cobb/Santa Teresa/IBM @ IBMUS VM Address: STLPS(EECOBB) Phone: 1-408-463-2458 (T/L 543) FAX: 1-408-463-4101 (T/L 543) Epilogue: 5. Issue 304 - OTS v2 Synchronization - I'm not sure I understand this issue nor can I find a note in my mail which seems to be its genesis.