Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C0A26200BC2 for ; Thu, 17 Nov 2016 18:57:09 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id C049D160B0B; Thu, 17 Nov 2016 17:57:09 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E6375160AD8 for ; Thu, 17 Nov 2016 18:57:08 +0100 (CET) Received: (qmail 29196 invoked by uid 500); 17 Nov 2016 17:57:08 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 29186 invoked by uid 99); 17 Nov 2016 17:57:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2016 17:57:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A0F00180538 for ; Thu, 17 Nov 2016 17:57:07 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.38 X-Spam-Level: ** X-Spam-Status: No, score=2.38 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-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 (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 1PC5ROWH8XCO for ; Thu, 17 Nov 2016 17:57:05 +0000 (UTC) Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 6F0305F295 for ; Thu, 17 Nov 2016 17:57:05 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id 137so148635207vkl.0 for ; Thu, 17 Nov 2016 09:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4IAmq78u80KoKBCA9cLkYXJyUtYeDpuxUI8i5+SO91Q=; b=LG9Q8Gi67uPdW6M97HARNMXgOiJg9eU3xuqYv3OkADj3/JzTk3yBper3Th9U+aI9PB na9j2Rpjv7qiCByxpa5GIcca1NIJmCvdXInnu5AtSv1PsZwfce6tDlEuC+o0BTmKZvVY 4CmFQs1x6XPYJ9j8uFH4NE6KPyq9qxkWcY9bCa0HKP+HOISioHY2c3UBIBM3mx2zq7xN CfLBSlIetCj7m10uBGATXUW3UDSpzZE9qIN45KXWC7cXvtSC5JvFbxkjMAuQE3MthJe0 ZXudv7PLFNazmRYncRRgriy04t3NUtH+OWr+Gci9DBNSWNVW7UD+E5as4f/W56RBHa0T zASw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4IAmq78u80KoKBCA9cLkYXJyUtYeDpuxUI8i5+SO91Q=; b=cqvid1kasHRgqVCv1kPnVDfJCE5Le0jQecCKWxqlYbjhg+iR2KK5R5kfrkcNlBHxO4 YOqgSzf078wPGVhEXdf6NWuNOQyNUjdT5bbei8ZxxdolZ53UT91g0CnshrDpsWmMoTne DRabDGradgAXjvOdo8BnLP0hH2grD4JoLNHlOoZTRrA/FocStbsTMrQdDbd+ucMsaN2V AG9rdwZQV+eq2PXLVCIhEVuFlUYCFBlmTehwLw1ZMdGdbEIkflquuSYyQBVa71mNX0IP BrCMRqO2g5sAhG3QKeckpxOGZMT+pLi/y+yxmIekIlAE/n/BdcYtb78zcjI6nJEQZqB9 t4Ag== X-Gm-Message-State: AKaTC02CziqV+hbXxAk6/AlvoRp9zBc4bP3JGs7VcySmQam+vg2djOT0zoVgqBtxNn7sk1ecu/fDXQpSWrZG9g== X-Received: by 10.31.191.194 with SMTP id p185mr2572201vkf.98.1479405424703; Thu, 17 Nov 2016 09:57:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.32.38 with HTTP; Thu, 17 Nov 2016 09:57:04 -0800 (PST) In-Reply-To: <1479404050670-9055.post@n6.nabble.com> References: <1479304724484-9018.post@n6.nabble.com> <1479328516749-9029.post@n6.nabble.com> <1479383128261-9042.post@n6.nabble.com> <1479397963122-9053.post@n6.nabble.com> <1479404050670-9055.post@n6.nabble.com> From: Alexey Goncharuk Date: Thu, 17 Nov 2016 20:57:04 +0300 Message-ID: Subject: Re: Order of transaction commit, cache update and event listener notification To: user@ignite.apache.org Content-Type: multipart/alternative; boundary=001a114db026d17a71054182eae8 archived-at: Thu, 17 Nov 2016 17:57:09 -0000 --001a114db026d17a71054182eae8 Content-Type: text/plain; charset=UTF-8 Hi, Currently SQL queries do not participate in transactions in any way, so you can see partially committed data from other transactions. In other words, if a thread 1 updates keys 1, 2, 3, 4 and started transaction commit, and thread 2 issues an SQL query, this query may see keys 1, 2 updated and keys 3, 4 - not. As Vlad mentioned, there is a ticket for supporting transactional SQL [1] which you can track (and join discussion regarding the design, btw). Hope this helps, AG [1] https://issues.apache.org/jira/browse/IGNITE-3478 2016-11-17 20:34 GMT+03:00 newbie : > Thanks for the info and link. > > Just an add-on question based on the link: > > Do the sql queries really see another transaction's dirty data with > OPTIMISTIC, REPEATABLE_READ ? > > From my testing it seems like if we are writing from transaction T1 and > reading from a different thread in transaction T2, I don't really see Sql > query returning uncommitted data from T1. Have I missed something here ? > > > > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/Order-of-transaction-commit-cache- > update-and-event-listener-notification-tp9018p9055.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. > --001a114db026d17a71054182eae8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Currently SQL queries do not partic= ipate in transactions in any way, so you can see partially committed data f= rom other transactions.=C2=A0

In other words, if a= thread 1 updates keys 1, 2, 3, 4 and started transaction commit, and threa= d 2 issues an SQL query, this query may see keys 1, 2 updated and keys 3, 4= - not.

As Vlad mentioned, there is a ticket for s= upporting transactional SQL [1] which you can track (and join discussion re= garding the design, btw).

Hope this helps,
AG



2016-11-17 20:34 GMT+03:00 newbie <lists.my@gmail.com>= :
Thanks for the info and link.
Just an add-on question based on the link:

Do the sql queries really see another transaction's dirty data with
OPTIMISTIC, REPEATABLE_READ ?

From my testing it seems like if we are writing from transaction T1 and
reading from a different thread in transaction T2, I don't really see S= ql
query returning uncommitted data from T1. Have I missed something here ?





--
View this message in context: http://ap= ache-ignite-users.70518.x6.nabble.com/Order-of-transaction-commit= -cache-update-and-event-listener-notification-tp9018p9055.html
Sent from the Apache Ignite Users m= ailing list archive at Nabble.com.

--001a114db026d17a71054182eae8--