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 4A91C200BE1 for ; Mon, 19 Dec 2016 18:36:19 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 49386160B21; Mon, 19 Dec 2016 17:36:19 +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 90FA6160B14 for ; Mon, 19 Dec 2016 18:36:18 +0100 (CET) Received: (qmail 27196 invoked by uid 500); 19 Dec 2016 17:36:17 -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 27185 invoked by uid 99); 19 Dec 2016 17:36:17 -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, 19 Dec 2016 17:36:17 +0000 Received: from [192.168.1.64] (108-193-4-186.lightspeed.sntcca.sbcglobal.net [108.193.4.186]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 704531A028B for ; Mon, 19 Dec 2016 17:36:17 +0000 (UTC) From: Denis Magda Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Communication from JDBC/ODBC drivers Date: Mon, 19 Dec 2016 09:36:16 -0800 References: <0B7F19C7-231D-4C3F-83C6-D232059B8CF9@apache.org> <759FAA7E-FB31-4449-BE35-C7C597E3731C@apache.org> To: dev@ignite.apache.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) archived-at: Mon, 19 Dec 2016 17:36:19 -0000 Dmitriy, According to Val and Alex P. explanations this happens when a specific = node id is set. I got confused by the code flow initially. =E2=80=94 Denis > On Dec 19, 2016, at 9:13 AM, Dmitriy Setrakyan = wrote: >=20 > Thanks, Alex. >=20 > Can you clarify if the putAll(...) call is made directly, or from = locally > executed callable? According to Denis, "even single (non batched) = updates > or queries are sent as callables", which should be fixed in my view. >=20 > D. >=20 > On Mon, Dec 19, 2016 at 3:32 AM, Alexander Paschenko < > alexander.a.paschenko@gmail.com> wrote: >=20 >> Dima, Val, >>=20 >> Introduction of updates has not changed public API at all (only >> configuration, in some cases), so they work in this respect exactly >> like SELECTs - by default they run on client node started by the >> driver itself, but can be sent via the same callables mechanism to = any >> remote node by its id. >>=20 >> So Dima, you're right, currently it's possible to send query to any >> given node. And, at the same time, currently by default everything >> works exactly like you want it to - that is, any MERGE, batched or >> not, boils down to putAll, and by default this call happens locally. >>=20 >> - Alex >>=20 >> 2016-12-17 18:47 GMT+03:00 Dmitriy Setrakyan : >>> On Fri, Dec 16, 2016 at 9:53 PM, Valentin Kulichenko < >>> valentin.kulichenko@gmail.com> wrote: >>>=20 >>>> I'm not sure about updates, but can tell about how selects are >> implemented >>>> there. Basically, there is an option to execute the query on a >> particular >>>> node specified by ignite.jdbc.nodeId property. Not sure why we need = this >>>> though, probably it's just leftover from the legacy version of the >> driver >>>> based on thin client. >>>>=20 >>>> If the property is set, the callable is sent to a remote node. But = if >> it is >>>> not, the same callable is created, but it is invoked directly on = the >>>> embedded client which is the behavior that you expect. And it's the >> default >>>> one. >>>>=20 >>>>=20 >>> Ouch. If this is the reason, I would drop the nodeId property. I = don't >>> think it makes sense and it significantly slows down the = implementation. >>>=20 >>>=20 >>>> -Val >>>>=20 >>>> On Fri, Dec 16, 2016 at 7:51 PM, Denis Magda = wrote: >>>>=20 >>>>> Frankly speaking, even single (non batched) updates or queries are >> sent >>>> as >>>>> callables. This is what I see in the code. >>>>> No idea what was the reason behind this design. >>>>>=20 >>>>> Andrey G., Alex P. could you shed a light on this? >>>>>=20 >>>>> =E2=80=94 >>>>> Denis >>>>>=20 >>>>>> On Dec 16, 2016, at 3:08 PM, Dmitriy Setrakyan < >> dsetrakyan@apache.org> >>>>> wrote: >>>>>>=20 >>>>>> To my understanding, we are implementing JDBC batches by sending = a >>>>> callable >>>>>> to another node. If we already have a client node on the JDBC = driver >>>>> side, >>>>>> why not just issue a putAll(...) call from the client? >>>>>>=20 >>>>>> D. >>>>>>=20 >>>>>> On Fri, Dec 16, 2016 at 3:02 PM, Denis Magda >>>> wrote: >>>>>>=20 >>>>>>> Dmitriy, >>>>>>>=20 >>>>>>> JDBC drivers spawns an Ignite client node and uses it for = cluster >>>>>>> connectivity and queries execution. Queries issued over the JDBC >> are >>>>> turned >>>>>>> into SqlFieldsQueries and sent to the cluster in this form. >>>>>>>=20 >>>>>>> ODBC driver works in a bit different way. It connects to the >> cluster >>>> via >>>>>>> ODBC processor that needs to be running on one of the nodes: >>>>>>> https://apacheignite.readme.io/docs/odbc-driver#cluster- >> configuration >>>> < >>>>>>> https://apacheignite.readme.io/docs/odbc-driver#cluster- >> configuration >>>>>=20 >>>>>>>=20 >>>>>>> =E2=80=94 >>>>>>> Denis >>>>>>>=20 >>>>>>>> On Dec 16, 2016, at 2:41 PM, Dmitriy Setrakyan < >>>> dsetrakyan@apache.org> >>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Igniters, >>>>>>>>=20 >>>>>>>> Can someone explain to me how Ignite executes SQL from JDBC and >> ODBC >>>>>>>> drivers? Do we start an Ignite client node on the driver side? = Or >> do >>>> we >>>>>>> use >>>>>>>> some other protocol to send commands to one of the Ignite = nodes? >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> D. >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>=20