From dev-return-3319-archive-asf-public=cust-asf.ponee.io@servicecomb.apache.org Mon Apr 2 16:54:24 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6420D180627 for ; Mon, 2 Apr 2018 16:54:23 +0200 (CEST) Received: (qmail 22197 invoked by uid 500); 2 Apr 2018 14:54:22 -0000 Mailing-List: contact dev-help@servicecomb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@servicecomb.apache.org Delivered-To: mailing list dev@servicecomb.apache.org Received: (qmail 22179 invoked by uid 99); 2 Apr 2018 14:54:21 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2018 14:54:21 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 78798C61F4 for ; Mon, 2 Apr 2018 14:54:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.879 X-Spam-Level: ** X-Spam-Status: No, score=2.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_LIVE=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id cmLByOTWw4AH for ; Mon, 2 Apr 2018 14:54:19 +0000 (UTC) Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 1A8F95FB37 for ; Mon, 2 Apr 2018 14:54:19 +0000 (UTC) Received: by mail-wm0-f47.google.com with SMTP id i3so3903526wmf.3 for ; Mon, 02 Apr 2018 07:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=CgelgBzdvy0R5Ub3n/4wG+jKI78lysecyNxTv7FTzls=; b=JPFfjkISBNokStwCHahzSiXPEEdpGLacbAfOJYqtO7v4I8e8lIimXuNl1bhACc5r/a G6lnyW0OFdAgMs0Q4jXEiOG/gQI4Q0xt3//9w9Ooevgl77M5KB0/03pgebNhNSEsC+zI 8gEyTCuo8F7NdISx16xJqFqTbmT0CVBIVhsv+kQnOXc0Sf+AVkyyGir+oWlHzBisb2fn 72hzcIBPCb+BZFPiUMHqvzkTFZtfD7B6xkqSorwq5yQwBl5+VHjnSGHe4WoJEBU4r9r4 6ycNk2/OC5BXHPlsozXGISNBV3+qkZqjMdDnSZugmWJohjZSn1Tp3N47b0Dbnf7HrUrM P3sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=CgelgBzdvy0R5Ub3n/4wG+jKI78lysecyNxTv7FTzls=; b=SHSeXApcgzpW56mOKNEomtCAk4DIb7jn0nPc0ZoSrcebsv2q97YeH3kJXqnI8uPS1f t6hDVvIQG8cx6PBejTo6f8s9urHRUjcHsdDDOPdPmLK+IZHlJRs9eC/ybVyHI8NG48/3 quhuzOkWF0Lij8Uor3UQINtdE4KIXAT5oDW0TTTN+VqD0B//TJcZggXDiyJSKVsupcd9 5Nn8UITUED9cF2oSEmQGKpkfNWZgVmkxHEWf0xl4waFUKs++uCo1oa8sulRK9wX2LtbF 8IhN/JUR84TLVK6JDpl3sMK3TFIdKgnc7qsVkihGQqMkpXAA314uI/JddtYlfZzOhK+m 2Z0Q== X-Gm-Message-State: ALQs6tCEWohs2ZrYZbdSCuJEmbyUnLswfOdxLWFtuSStY5KvzsONB2J5 1kGK6L9nDSrASR/PgjXBmeZQvNgxE9KVt1dEGxCX7TmI X-Google-Smtp-Source: AIpwx4/xu2yF9WnaBrAdUEVmxi0MF9scZnxwPA09iJtbogZ29GKW/rcuWpj23UwXba/yagnTP6HSv4YB1vQ6WQNh1bA= X-Received: by 10.28.192.7 with SMTP id q7mr1126372wmf.44.1522680858452; Mon, 02 Apr 2018 07:54:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.168.76 with HTTP; Mon, 2 Apr 2018 07:54:17 -0700 (PDT) In-Reply-To: References: From: Willem Jiang Date: Mon, 2 Apr 2018 22:54:17 +0800 Message-ID: Subject: Re: [Discussion] compatible TCC support in Saga To: dev@servicecomb.apache.org Content-Type: multipart/alternative; boundary="089e08316058aca74d0568dec367" --089e08316058aca74d0568dec367 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Chris just gave a talk[1] recently about the countermeasure for data anomalies. It made us to think if we can find a better way to resolve the isolation issues. It looks like the TCC pattern can prevent the uncommitted states to be saw by adding the try phases. And this is what current saga solution is missed. With help of temp table to store the status of the try operation, we don't need the coordinator handle much unnormal situation. It could be better if we don't let the user know about the temp table. But the challenge is how can we hide the temp table to the user. [1] http://microservices.io/microservices/general/2018/03/22/microxchg-sagas.ht= ml Willem Jiang Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: =E5=A7=9C=E5=AE=81willem On Mon, Apr 2, 2018 at 5:57 PM, Eric Lee wrote: > Hi, all > > As we have discussed the ACID guarantees Saga provides in the previous > thread[1], it turns out Saga does not provide isolation guarantee. To > improve user experience, the business logic using Saga may need to reorde= r > to make sure the user-sensitive sub-transaction is the last one to be > executed. In sceanrios require full ACID support, the implementaion of Sa= ga > may need to be compatible with the TCC[2] pattern with an extra try phase= . > > Take a transfer application as an example, it contains transfer in and > transfer out service of two different databases. From the customer's view= , > the transfer in and transfer out operation is an atomic operation which > requires both to be executed or nothing executed. However, in the middle = of > the overall transaction, e.g. the sub transaction of transfer out is done > and the sub transaction of transfer in is not done yet, if a customer > checkouts out his/her balance, it will become weird as the balance is not > equal. The isolation is corrupted at this moment in Saga. > In TCC, the isolation could be solved using either the reservation or > compensation which depends on your bussiness logic. > Reservation: In try phase, use a temporal table to store the credit and > transaction context. In commit phase, reduce the balance in the account a= nd > remove the temporal table. If anything goes wrong, it can execute the > cancel method to remove the temporal table. In this way, if the global > transaction fails, it will take no effect on the actual table. Besides, > when a customer visits his/her balance, we can simply return the value in > the actual table which is the original value before this transaction > executed. > Compensation: In try phase, use a temporal table to record the compensate= d > value and reduce the balance in the account. In commit phase, remove the > temporal table. If anything goes wrong, it can execute the cancel method > to recover the balance according to the temporal table and remove the > temporal table afterward. In this way, when a customer visits his/her > balance, we can do simple calculation of the value in actual table and > temporal table to return the origianl value before the transaction > executed. > > Within transaction ids in the table row, each create/update/delete > operation is idempotent and it simplies a lot of work to make sure > sub-transactions are idempotent. > > > Any other ideas or suggestions on the isolation support in Saga are > welcome. Thanks. > > > [1] https://lists.apache.org/list.html?dev@servicecomb.apach > e.org:lte=3D1M:a%20question%20about%20acid%20 > [2] http://design.inf.usi.ch/sites/default/files/biblio/rest-tcc.pdf > > > Best Regards! > Eric Lee > --089e08316058aca74d0568dec367--