From dev-return-2311-archive-asf-public=cust-asf.ponee.io@tephra.incubator.apache.org Tue Dec 11 19:21:30 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 A607E180671 for ; Tue, 11 Dec 2018 19:21:29 +0100 (CET) Received: (qmail 2255 invoked by uid 500); 11 Dec 2018 18:21:28 -0000 Mailing-List: contact dev-help@tephra.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tephra.incubator.apache.org Delivered-To: mailing list dev@tephra.incubator.apache.org Received: (qmail 2243 invoked by uid 99); 11 Dec 2018 18:21:28 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Dec 2018 18:21:28 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id C6DADC1D50 for ; Tue, 11 Dec 2018 18:21:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.047 X-Spam-Level: ** X-Spam-Status: No, score=2.047 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id g4A9CQ8UnK9s for ; Tue, 11 Dec 2018 18:21:25 +0000 (UTC) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 285A860E0B for ; Tue, 11 Dec 2018 18:21:25 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id h15so13367929edb.4 for ; Tue, 11 Dec 2018 10:21:25 -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=HBYPScq9z4gMtycAdXIy9Mr/GKOn1eo97SL2jQQJB60=; b=op9jkFlNgib8SI7daNz8+vzFSS7iOY8U+9VTXCKf8gnwvT+3FL1AE7+VQ6rW3j8IWu pV9mL2g1gf9zu/9Klj0TMvI+BWi057yCCsZahv1WIn4BpSQy5EJyknwJmgFw2A98r9E+ wJVqZi7bef2OhhIggLwahM1ky9wVxtOMHkS1P9zRu49wGO8OJhvDcFeK7P8idQsALOUR SX7+UvzVewevu5LB9OPJz5SJRdWKVW4zJaBlBGcs5e3kEGSXf/ixdNn52dCGLcp2fnEl IVEAoZiUGUN/M8THMQx3FgD3eAeukk3PKigBj+N4uYu2O4LdNT5L/gQekERCXC1IxmJt IYyQ== 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=HBYPScq9z4gMtycAdXIy9Mr/GKOn1eo97SL2jQQJB60=; b=Gt1U/3U66YpZ5IprUazXGunyci56dE1Q6yoTt2YxVdPbrYMoAUn9iZg6zrq131ccLj xcRQD1Tvd/Q66VtdWrNIHSOjccT429pW7hum9wpc7oU8mu4ztA04jkhI9JmQtSMwpC7N 2J4aZwDgez/PzTpAvxv+EpKmrZGcM16ibLkeqstVDc/CVvP5MXdL++LTqBtl4OSH7HGS U43ijn8q/i6qmWAAVS0I9ffu7JbdqMjyprw+VPSyGxvmi2DKUtZz/p4CV4R7VlhH25mg 8dMqGVeQpv4mMLwUOBgtOQx2bsYeDA65tN59ld/KKAObIn9IvVc4R60DQT5KaCtnjUkj t2AA== X-Gm-Message-State: AA+aEWaZH09v4hlC0jwBYRTncvTgi7FkZ57JpUXOuaqTYAMmHdKUxMRb QhDIoZDqmucsqcSSk10FOqEI5z8GjFIs4cqQ2n6VsRmo X-Google-Smtp-Source: AFSGD/WaKd10/mEU9L6XAcoRbEegwaf0bwrV7fCOHRZMNVRlPco/EdAOGZql1MhUfoNtuj1gq/NRNJKRxmWWfeVNkj4= X-Received: by 2002:a17:906:a88c:: with SMTP id ha12-v6mr13208338ejb.107.1544552483855; Tue, 11 Dec 2018 10:21:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Varun Rao Date: Tue, 11 Dec 2018 13:21:12 -0500 Message-ID: Subject: Re: SELECT after INSERT shows missing data To: dev@tephra.incubator.apache.org Content-Type: multipart/alternative; boundary="0000000000002322ea057cc3268e" --0000000000002322ea057cc3268e Content-Type: text/plain; charset="UTF-8" Thanks for the quick reply Andreas - Spring's Propagation.REQUIRED option is being used, so our understanding is that a nested @Transactional will re-use the existing transaction context if one exists (we also need the two operations to happen together, as one transaction): https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Propagation.html#REQUIRED This is intermittent behavior - the first insert has always been visible from checkToEnsureObj1WasInserted() other than the single failure that was observed last week (And we expect the first insert to be visible within the transaction context given snapshot isolation and the Phoenix documentation: https://phoenix.apache.org/transactions.html) Just to confirm, as we understand it Tephra provides snapshot isolation (rather than the ANSI sql92 isolation levels.. read_committed, repeatable_read, serializable). So the fact that we are passing READ_COMMITTED at the Spring level should not be relevant to the isolation that Tephra provides, is that accurate? Is there particular logging that we can look for (or enable, if needed) to confirm: 1) our transactions are in-fact using Tephra snapshot isolation 2) any lower level Tephra transaction details which may help us troubleshoot this issue, if and when it occurs again? Thanks very much On Tue, Dec 11, 2018 at 12:05 PM Andreas Neumann wrote: > Hey Varun, > > I think the issue is that your code starts the second transaction before > the first one has committed (inside the outer @Transactional). Because of > snapshot isolation, the second transaction cannot see the writes from the > first one. I see tw ways to make it work: > > 1. Remove the @Transactional from insertInner(). That way it is part of the > same transaction and will see the write of obj1. > 2. Serialize the transactions. It should work if rewrite your code to > something like this: > > void insertBoth(Object obj, Object obj2) throws someException { > insertOuter(obj1); > insertInner(obj1, obj2); > } > > @Transactional > void insertOuter(Object obj1, Object obj2) throws SomeException { > // Spring call to insert obj1 into Phoenix transactional table1 > } > > @Transactional > void insertInner(Object obj) throws SomeException { > checkToEnsureObj1WasInserted() // ** THIS FAILS > ... // code to insert object 2 > } > > Cheers -Andreas. > > On Tue, Dec 11, 2018 at 7:05 AM Varun Rao wrote: > > > Hello, > > > > We have an application that issues two sequential inserts within the same > > Phoenix/Tephra transaction. Before the second insert, a check is > performed > > to ensure data from the first insert is available (select ...). This > check > > failed once in production (an intermittent problem which has not been > > reproduced). Phoenix/Tephra is being accessed through > > Spring (which uses Java Transaction API) with 'read committed' and > > 'propagation.required' options. The code is similar to the following: > > > > @transactional > > void insertOuter(Object obj1, Object obj2) throws SomeException { > > // Spring call to insert obj1 into Phoenix transactional table1 > > insertInner(obj2) > > } > > > > @Transactional > > void insertInner(Object obj) throws SomeException { > > checkToEnsureObj1WasInserted() // ** THIS FAILS > > ... // code to insert object 2 > > } > > > > We expect to see that subsequent write operations within the same Phoenix > > transactions are guaranteed to see the results of prior operations (the > > second write will have access to the first write) > > > > 1) Should Java Spring be compatible with Phoenix/Tephra? > > 2) Is there a particular Phoenix/Tephra logging configuration that can > be > > enabled to capture additional transaction-specific information, such as > > when commits or rollbacks occur? > > > > Thanks very much > > > --0000000000002322ea057cc3268e--