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 04FF9200CF6 for ; Mon, 4 Sep 2017 05:38:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 035FE163B6F; Mon, 4 Sep 2017 03:38:22 +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 23A2B163B6E for ; Mon, 4 Sep 2017 05:38:20 +0200 (CEST) Received: (qmail 14893 invoked by uid 500); 4 Sep 2017 03:38:20 -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 14884 invoked by uid 99); 4 Sep 2017 03:38:19 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Sep 2017 03:38:19 +0000 Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 601A81A00DF for ; Mon, 4 Sep 2017 03:38:18 +0000 (UTC) Received: by mail-qt0-f174.google.com with SMTP id w42so18471810qtg.5 for ; Sun, 03 Sep 2017 20:38:18 -0700 (PDT) X-Gm-Message-State: AHPjjUhMGSXi8kUfX5Ia6A+e39uoegxY6GSkxYe5AMGEpdyNSSHEr9ug mFYFm+wZusGcASgJupp0k+E2nyqQzlEA X-Google-Smtp-Source: ADKCNb5lRzItlHtl/5l/5pXvdmZjFyFvs8LurEe1IU4q9TIZNMKeaYjRJNQ30K3IDPhmpWiNaOdWbL5s6lB4SJraMFQ= X-Received: by 10.200.22.38 with SMTP id p35mr6136957qtj.59.1504496297152; Sun, 03 Sep 2017 20:38:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.34.6 with HTTP; Sun, 3 Sep 2017 20:37:36 -0700 (PDT) In-Reply-To: <8F4F0232-A20E-4FF3-B45D-664741A845DB@apache.org> References: <1504077665119-0.post@n6.nabble.com> <8F4F0232-A20E-4FF3-B45D-664741A845DB@apache.org> From: Dmitriy Setrakyan Date: Sun, 3 Sep 2017 20:37:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Ignite sql queries working transactionally To: user Content-Type: multipart/alternative; boundary="f403045d64e85ba7ba055854d77e" archived-at: Mon, 04 Sep 2017 03:38:22 -0000 --f403045d64e85ba7ba055854d77e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Denis, I think you provided an incorrect link to the ticket. Here is the correct link: https://issues.apache.org/jira/browse/IGNITE-3478 D. On Wed, Aug 30, 2017 at 5:50 PM, Denis Magda wrote: > Hi, > > The docs are still valid - SQL operations are not fully transactional yet > and, according, to JIRA the works is in progress to make this happen: > https://ggsystems.atlassian.net/browse/IGN-4666 > > =E2=80=94 > Denis > > > On Aug 30, 2017, at 12:21 AM, kotamrajuyashasvi < > kotamrajuyashasvi@gmail.com> wrote: > > Hi > > In my ignite client application I need to perform a set of update/delete > sql > query operations transactionally. I observed that by using ignite > transactions I was able to achieve this. When ever an update or delete > query > is executed with in a transaction, it is locking all resulting rows and > thus > preventing other clients modify/delete the same rows using update/delete > queries. I checked this in the following way. > > First I started an Ignite client and started a Transaction. Then I execut= ed > an update query acting up on some rows. Then I made this client to sleep > for > some seconds before committing the transaction. Now I immediately started > another client and tried executing a delete query which would act upon th= e > same or few of the rows as the update query in first client. Now I could > observe that the second client waits till the first client commits and on= ly > then it executes its delete query. > > Rollback functionality is also working on update/delete queries. So does = it > mean that ignite now supports fully transactional sql queries? It was > mentioned in many previous ignite users posts that ignite sql queries are > not transactional and also in 2.1 docs its mentioned that '*At SQL level > Ignite supports atomic, but not yet transactional consistency. Ignite > community plans to implement SQL transactions in version 2.2*.'. What doe= s > it mean? Also no where in docs mentions about using sql queries in > transactions. > > can I use ignite jdbc thin client with sql queries and transactions? > > I am using ignite version 2.1 > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > > > --f403045d64e85ba7ba055854d77e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Denis, I think you provided an incorrect link to the ticke= t. Here is the correct link:


D.

On Wed, Aug 30, 2017 at 5:50 PM, De= nis Magda <dmagda@apache.org> wrote:
Hi,

The d= ocs are still valid - SQL operations are not fully transactional yet and, a= ccording, to JIRA the works is in progress to make this happen:
<= a href=3D"https://ggsystems.atlassian.net/browse/IGN-4666" target=3D"_blank= ">https://ggsystems.atlassian.net/browse/IGN-4666

=E2=80=94
Denis
=C2=A0
On Aug 30, 2017, at 12:21 AM, kotamrajuyashasvi &l= t;kotamraj= uyashasvi@gmail.com> wrote:

Hi

In my ignite client applicat= ion I need to perform a set of update/delete sql
query operations transa= ctionally. I observed =C2=A0that by using ignite
transactions I was able= to achieve this. When ever an update or delete query
is executed with i= n a transaction, it is locking all resulting rows and thus
preventing ot= her clients modify/delete the same rows using update/delete
queries. I c= hecked this in the following way.

First I started an Ignite client = and started a Transaction. Then I executed
an update query acting up on = some rows. Then I made this client to sleep for
some seconds before comm= itting the transaction. Now I immediately started
another client and tri= ed executing a delete query which would act upon the
same or few of the = rows as the update query in first client. Now I could
observe that the s= econd client waits till the first client commits and only
then it execut= es its delete query.

Rollback functionality is also working on updat= e/delete queries. So does it
mean that ignite now supports fully transac= tional sql queries? It was
mentioned in many previous ignite users posts= that ignite sql queries are
not transactional and also in 2.1 docs its = mentioned that '*At SQL level
Ignite supports atomic, but not yet tr= ansactional consistency. Ignite
community plans to implement SQL transac= tions in version 2.2*.'. What does
it mean?=C2=A0 Also no where in d= ocs mentions about using sql queries in
transactions.

can I use i= gnite jdbc thin client with sql queries and transactions?

I am using= ignite version 2.1





--
Sent from: http://apach= e-ignite-users.70518.x6.nabble.com/


--f403045d64e85ba7ba055854d77e--