From dev-return-49560-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Feb 4 11:48:36 2020 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9F1B018064E for ; Tue, 4 Feb 2020 12:48:36 +0100 (CET) Received: (qmail 63921 invoked by uid 500); 4 Feb 2020 11:48:36 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 63908 invoked by uid 99); 4 Feb 2020 11:48:35 -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; Tue, 04 Feb 2020 11:48:35 +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 2BDBCC08C3 for ; Tue, 4 Feb 2020 11:48:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id WdPxltJaSWVH for ; Tue, 4 Feb 2020 11:48:33 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.217.49; helo=mail-vs1-f49.google.com; envelope-from=alexey.scherbakoff@gmail.com; receiver= Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id ACF2FBB806 for ; Tue, 4 Feb 2020 11:48:33 +0000 (UTC) Received: by mail-vs1-f49.google.com with SMTP id v141so11066605vsv.12 for ; Tue, 04 Feb 2020 03:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oypvZiULARkUnrQU8C1beJOjvaoj2xvGI4ViqSebYhE=; b=m5oiaySUoxQ+juiY8jX3XMsdZ6Re3N+pOvAAp6br9Pq+f8XrjAfExqpUpqZjvUPjaW nFuN5aRymNkSZCS5IzPghAYoejqEdq8u9JgMt0Cpq3eaM1KZeBKEoMwSmFJfMJPs+9ni cZPtHxVdXWc2Rpri5iOrbrj70hNiYAuyCTW65jNVfjvI04wYIBsgA3f4KtuCGsU0S9nd 4U6FAzqbQmlqzOVbK3eSepKnONgMakiaixRLOmSMRRJsWREX8dRUc5OsOx1kR6aPqXeX c4pBUQ8rTV4XFkF4NNjbBoIiSSH8hOwwUAw8vaR9kZ7TkUB7o8fwuzP5TWlI1zMlbNH6 Qp7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oypvZiULARkUnrQU8C1beJOjvaoj2xvGI4ViqSebYhE=; b=DP3c6j7Vo6vtNfVgMf5GQVMDmxbRGp9i66C5OMdwYXokT7LImv7vMBhHok1crCHjel LdwAZojZzoa2ierW9+8/wrP568R8x9R8Z4+9O4wYtBrdwkArRCa9bFnSn9f+xQ3PS2X5 s7QVcVkjbdAFJ4zpVfXz77kuPm/D5JTfdIPZH3w/0K/1qTiLAEOHCt1lQ+6Uo80sK50v UmxZDD1pNRGSbY5czZ1FIgN+rQJhVPEWOgPGCWhGd1T+X9FjLXzEqS8fDGysuUwajMiI xsFDzAZWSK1WGqTeb2/LeqKAsha3FVmqllUqx1HJXKI+rXPKILYVuVMeXY5dmpFC5x3p Sbxw== X-Gm-Message-State: APjAAAUvZHJGitajAz2Z3JRDo5pcA63bW/rYU18oO2lmztKiHNTwyVf4 xVBAtd1kwgJUi5/u+ODKBGVaJdRra/KKr81SUnk/4Q== X-Google-Smtp-Source: APXvYqzllQ9s6bXfw6/ZX0jU0vBWKAe0qi2yzwIx+ah/hwoq9TI002PJVOFArvJ+CGkXLLc2Ja2LYjk+LfsBfG5Axc4= X-Received: by 2002:a67:f852:: with SMTP id b18mr17774469vsp.131.1580816913057; Tue, 04 Feb 2020 03:48:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexei Scherbakov Date: Tue, 4 Feb 2020 14:48:23 +0300 Message-ID: Subject: Re: Forbid mixed cache groups with both atomic and transactional caches To: dev Content-Type: multipart/alternative; boundary="0000000000008ecc9d059dbe9eb1" --0000000000008ecc9d059dbe9eb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to avoid mixed tx-atomic cache groups. On the other side, doing atomic ops inside a tx have no relation to described reasons and is acceptable for me. =D0=B2=D1=82, 4 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 14:40, Alexey= Goncharuk : > I support this change. While this has no much difference on the storage > level, the protocols are indeed are very different and thus should be > separated. > > =D0=B2=D1=82, 4 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3. =D0=B2 14:36, Anto= n Vinogradov : > > > Seems, we already started the separation by atomic operations restricti= on > > inside the transactions [1]. > > See no reason to allow mixes in this case. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-2313 > > > > On Tue, Feb 4, 2020 at 2:28 PM Ivan Rakov wrote= : > > > > > Igniters, > > > > > > Apparently it's possible in Ignite to configure a cache group with bo= th > > > ATOMIC and TRANSACTIONAL caches. > > > Proof: IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* > tests. > > > In my opinion, it would be better to remove such possibility from the > > > product. There are several reasons: > > > > > > 1) The original idea of grouping caches was optimizing storage overhe= ad > > and > > > PME time by joining data of similar caches into the same partitions. > > ATOMIC > > > and TRANSACTIONAL caches provide different guarantees and are designe= d > > for > > > different use cases, thus they can hardly be called "similar". > > > > > > 2) Diving deeper: synchronization protocols and possible reasons for > > > primary-backup divergences are conceptually different for ATOMIC and > > > TRANSACTIONAL cases. In TRANSACTIONAL case, transactions recovery > > protocol > > > allows to recover consistency if any participating node will fail, bu= t > > for > > > ATOMIC caches there's possible scenario with failure of primary node > > where > > > neither of backups will contain the most recent state of the data. > > Example: > > > one backup have received updates 1, 3, 5 while another have received > 2, 4 > > > (which is possible due to message reordering), and even tracking > counters > > > [1] won't restore the consistency. The problem is that we can't > > distinguish > > > what kind of conflict we have faced in case update counters have > diverged > > > in a mixed group. > > > > > > 3) Mixed groups are poorly tested. I can't find any tests except a > couple > > > of smoke tests in IgniteCacheGroupsTest. We can't be sure that > different > > > synchronization protocols will work correctly for such configurations= , > > > especially under load and with a variety of dependent configuration > > > parameters. > > > > > > 4) I have never heard of any feedback on mixed groups. I have asked > > > different people on this and no one recalled any attempts to configur= e > > such > > > groups. I believe that in fact no one has ever tried to do it. > > > > > > Please let me know if you are aware of any cases where mixed groups a= re > > > used or reasons to keep them. Otherwise I'll create a ticket to > prohibit > > > mixed configurations. > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11797 > > > > > > -- > > > Best Regards, > > > Ivan Rakov > > > > > > --=20 Best regards, Alexei Scherbakov --0000000000008ecc9d059dbe9eb1--