From dev-return-45565-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Apr 2 08:30:04 2019 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 BADAC180668 for ; Tue, 2 Apr 2019 10:30:03 +0200 (CEST) Received: (qmail 92379 invoked by uid 500); 2 Apr 2019 08:30:02 -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 92365 invoked by uid 99); 2 Apr 2019 08:30:01 -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, 02 Apr 2019 08:30:01 +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 3F09BC2D80 for ; Tue, 2 Apr 2019 08:30:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.113 X-Spam-Level: *** X-Spam-Status: No, score=3.113 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=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id JiMFqWW7LeC8 for ; Tue, 2 Apr 2019 08:29:57 +0000 (UTC) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 97C4F5F66C for ; Tue, 2 Apr 2019 08:29:56 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id l7so10735278ljg.6 for ; Tue, 02 Apr 2019 01:29:56 -0700 (PDT) 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=LOOFDCVcM9mhNjGwhTLgspN/2/7EP5oBIcBViwHsybs=; b=hXxsNvCUA2f7Ixfr7JffL/bFgvw1m1/sFpp3rOMFiEVEMi5mSq3OPpHC6foSaGD3DS 3KbPXeuUuANX0AQ5oW65MDVaEqCk5YzRl02l71A/TFIcVHVvMpW/tmiW0HATiDELDb08 zt7IUw5pQ/wDGfWeYbeWFKzswUnfccMDDp2UIFmW/uxXpCYbAWvlAjobGrKYmRUJ7AGZ 6ya68zyosW0sV8svTzcdavYsji/xVADio/jAfQpu0jRk6Lj+pJvBxk61qjaa3syUJsYS BJcExqt7CqNzFWH/OeEZ1R8SQmuZ6fRlQFMY+z7J0gKkE0GiwKjj4DQsIOEIbP361qOe dnMA== 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=LOOFDCVcM9mhNjGwhTLgspN/2/7EP5oBIcBViwHsybs=; b=qls3VNfLQwdK/NA351IqeoQW7OQ8N/nWz/INktzjS51VqxchIApX73BOWV3StaUe4R SwRf00rt6ZAVpNW9p4tZvYWgnjLqAzIZo9IMKPcfa+XdKPuLv9S2F0NBkMCarlrYP+Om 0mhIo/eZlNf+jpghaIm+siob5NYYIXt/BW14pqOd8HJnSCTM0vxzdFrnxyxTG49z0Mlr mh+TKg24XI0D17/XtWqkBJo/+TLULsrVpOToefQxeF7H2JmjSd9RYFkPzOvHOmMelJoi kYk50wJ4PI/k/+q8TScW6N7zqwt2Z4qIPKwgphmHU+YF/i3RkBNnAYsCVYRMfOkxvEDw jaOw== X-Gm-Message-State: APjAAAXNCGTj6wOJBwWEkUeHc1n1tovRloHJz86/twx0S0R/C78EwSp3 o0vEPHAg2dtd9JATar8iO2GVni6yMfyQAl2+zV8izQ== X-Google-Smtp-Source: APXvYqwGuuE9uVeWi7Po57wN6eOOojEYsH8d3cTiUmw49Rim67gxzZPxWLOxUfXywVLLw86lbDAzrp+4LO5KChlSEn8= X-Received: by 2002:a2e:3c0a:: with SMTP id j10mr13362458lja.164.1554193789445; Tue, 02 Apr 2019 01:29:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alex Plehanov Date: Tue, 2 Apr 2019 11:29:38 +0300 Message-ID: Subject: Re: Thin client: transactions support To: dev@ignite.apache.org Content-Type: multipart/alternative; boundary="000000000000bb6ac8058587f0c5" --000000000000bb6ac8058587f0c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pavel, AFAIK usually, such limitations handled by using connection pools. If a thread needs to start a transaction, it acquires a connection from the pool and releases the connection after the transaction end. =D0=B2=D1=82, 2 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 09:55, Pavel Tupits= yn : > Alex, > > > now we can only support one active transaction per connection > > I totally understand server-side and protocol limitations that are causin= g > this. > But I have no idea how to support this in .NET Thin Client, for example. > > It is thread-safe and can handle multiple async operations in parallel. > But with TX support we have to somehow switch to single-threaded mode to > avoid unexpected effects. > > Any ideas? > > > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov > wrote: > > > Dmitriy, thank you! > > > > Guys, I've created the IEP [1] on wiki, please have a look. > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+= transactions+support > > > > > > =D1=87=D1=82, 28 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 14:33, Dmitriy= Pavlov : > > > > > Hi, > > > > > > I've added permissions to account plehanov.alex > > > > > > Recently Infra integrated Apache LDAP with confluence, so it is > possible > > to > > > login using Apache credentials. Probably we can ask infra if extra > > > permissions to edit pages should be added for committers. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > =D1=81=D1=80, 27 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 13:37, Alex = Plehanov : > > > > > > > Vladimir, > > > > > > > > About current tx: ok, then we don't need tx() method in the interfa= ce > > at > > > > all (the same cached transaction info user can store by himself). > > > > > > > > About decoupling transactions from threads on the server side: for > now, > > > we > > > > can start with thread-per-connection approach (we only can support > one > > > > active transaction per connection, see below, so we need one > additional > > > > dedicated thread for each connection with active transaction), and > > later > > > > change server-side internals to process client transactions in any > > server > > > > thread (not dedicated to this connection). This change will not > affect > > > the > > > > thin client protocol, it only affects the server side. > > > > In any case, we can't support concurrent transactions per connectio= n > on > > > > the client side without fundamental changes to the current protocol > > > (cache > > > > operation doesn't bound to transaction or thread and the server > doesn't > > > > know which thread on the client side do this cache operation). In m= y > > > > opinion, if a user wants to use concurrent transactions, he must us= e > > > > different connections from a connection pool. > > > > > > > > About semantics of suspend/resume on the client-side: it's absolute= ly > > > > different than server-side semantics (we don't need to do > > suspend/resume > > > to > > > > pass transaction between threads on the client-side), but can't be > > > > implemented efficiently without implemented suspend/resume on > > > server-side. > > > > > > > > Can anyone give me permissions to create IEP on Apache wiki? > > > > > > > > =D1=81=D1=80, 27 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 11:59, Vla= dimir Ozerov : > > > > > > > > > Hi Alex, > > > > > > > > > > My comments was only about the protocol. Getting current info abo= ut > > > > > transaction should be handled by the client itself. It is not > > protocl's > > > > > concern. Same about other APIs and behavior in case another > > transaction > > > > is > > > > > attempted from the same thread. > > > > > > > > > > Putting protocol aside, transaction support is complicated matter= . > I > > > > would > > > > > propose to route through IEP and wide community discussion. We ne= ed > > to > > > > > review API and semantics very carefully, taking SUSPEND/RESUME in > > > count. > > > > > Also I do not see how we support client transactions efficiently > > > without > > > > > decoupling transactions from threads on the server side first. > > Because > > > > > without it you will need a dedicated server thread for every > client's > > > > > transaction which is slow and may even crash the server. > > > > > > > > > > Vladimir. > > > > > > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov < > > > plehanov.alex@gmail.com> > > > > > wrote: > > > > > > > > > > > Vladimir, what if we want to get current transaction info (tx() > > > > method)? > > > > > > > > > > > > Does close() method mapped to TX_END(rollback)? > > > > > > > > > > > > For example, this code: > > > > > > > > > > > > try(tx =3D txStart()) { > > > > > > tx.commit(); > > > > > > } > > > > > > > > > > > > Will produce: > > > > > > TX_START > > > > > > TX_END(commit) > > > > > > TX_END(rollback) > > > > > > > > > > > > Am I understand you right? > > > > > > > > > > > > About xid. There is yet another proposal. Use some unique per > > > > connection > > > > > id > > > > > > (integer, simple counter) for identifying the transaction on > > > > > > commit/rollback message. The client gets this id from the serve= r > > with > > > > > > transaction info and sends it back to the server when trying to > > > > > > commit/rollback transaction. This id is not shown to users. But > > also > > > we > > > > > can > > > > > > pass from server to client real transaction id (xid) with > > transaction > > > > > info > > > > > > for diagnostic purposes. > > > > > > > > > > > > And one more question: what should we do if the client starts a > new > > > > > > transaction without ending the old one? Should we end the old > > > > transaction > > > > > > implicitly (rollback) or throw an exception to the client? In m= y > > > > opinion, > > > > > > the first option is better. For example, if we got a previously > > used > > > > > > connection from the connection pool, we should not worry about > any > > > > > > uncompleted transaction started by the previous user of this > > > > connection. > > > > > > > > > > > > =D1=81=D1=80, 27 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 11:02,= Vladimir Ozerov < > vozerov@gridgain.com > > >: > > > > > > > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support them > yet, > > > and > > > > > > adding > > > > > > > them in future should not conflict with simple START/END > > > > > infrastructure. > > > > > > > > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov < > > > > vozerov@gridgain.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > I am not sure we need 5 commands. Wouldn't it be enough to > have > > > > only > > > > > > two? > > > > > > > > > > > > > > > > START - accepts optional parameters, returns transaction in= fo > > > > > > > > END - provides commit flag, returns void > > > > > > > > > > > > > > > > Vladimir. > > > > > > > > > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov < > > > > > plehanov.alex@gmail.com > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >> Sergey, yes, the close is something like silent rollback. > But > > we > > > > can > > > > > > > >> also implement this on the client side, just using rollbac= k > > and > > > > > > ignoring > > > > > > > >> errors in the response. > > > > > > > >> > > > > > > > >> =D1=81=D1=80, 27 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0=B2 0= 0:04, Sergey Kozlov < > > > skozlov@gridgain.com > > > > >: > > > > > > > >> > > > > > > > >> > Nikolay > > > > > > > >> > > > > > > > > >> > Am I correctly understand you points: > > > > > > > >> > > > > > > > > >> > - close: rollback > > > > > > > >> > - commit, close: do nothing > > > > > > > >> > - rollback, close: do what? (I suppose nothing) > > > > > > > >> > > > > > > > > >> > Also you assume that after commit/rollback we may need t= o > > free > > > > > some > > > > > > > >> > resources on server node(s)or just do on client started > TX? > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov < > > > > > > > plehanov.alex@gmail.com > > > > > > > >> > > > > > > > > >> > wrote: > > > > > > > >> > > > > > > > > >> > > Sergey, we have the close() method in the thick client= , > > it's > > > > > > > behavior > > > > > > > >> is > > > > > > > >> > > slightly different than rollback() method (it should > > > rollback > > > > if > > > > > > the > > > > > > > >> > > transaction is not committed and do nothing if the > > > transaction > > > > > is > > > > > > > >> already > > > > > > > >> > > committed). I think we should support try-with-resourc= e > > > > > semantics > > > > > > in > > > > > > > >> the > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful here. > > > > > > > >> > > > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for pessimisti= c > > > > > > > transactions. > > > > > > > >> > Also, > > > > > > > >> > > the main goal of suspend/resume operations is to suppo= rt > > > > > > transaction > > > > > > > >> > > passing between threads. In the thin client, the > > transaction > > > > is > > > > > > > bound > > > > > > > >> to > > > > > > > >> > > the client connection, not client thread. I think > passing > > a > > > > > > > >> transaction > > > > > > > >> > > between different client connections is not a very > useful > > > > case. > > > > > > > >> > > > > > > > > > >> > > =D0=B2=D1=82, 26 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. =D0= =B2 22:17, Nikolay Izhikov < > > > > > nizhikov@apache.org > > > > > > >: > > > > > > > >> > > > > > > > > > >> > > > Hello, Alex. > > > > > > > >> > > > > > > > > > > >> > > > We also have suspend and resume operations. > > > > > > > >> > > > I think we should support them > > > > > > > >> > > > > > > > > > > >> > > > =D0=B2=D1=82, 26 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2019= =D0=B3., 22:07 Sergey Kozlov < > > > > > skozlov@gridgain.com > > > > > > >: > > > > > > > >> > > > > > > > > > > >> > > > > Hi > > > > > > > >> > > > > > > > > > > > >> > > > > Looks like I missed something but why we need > > > OP_TX_CLOSE > > > > > > > >> operation? > > > > > > > >> > > > > > > > > > > > >> > > > > Also I suggest to reserve a code for SAVEPOINT > > operation > > > > > which > > > > > > > >> very > > > > > > > >> > > > useful > > > > > > > >> > > > > to understand where transaction has been rolled ba= ck > > > > > > > >> > > > > > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov < > > > > > > > >> > plehanov.alex@gmail.com > > > > > > > >> > > > > > > > > > > >> > > > > wrote: > > > > > > > >> > > > > > > > > > > > >> > > > > > Hello Igniters! > > > > > > > >> > > > > > > > > > > > > >> > > > > > I want to pick up the ticket IGNITE-7369 and add > > > > > > transactions > > > > > > > >> > support > > > > > > > >> > > > to > > > > > > > >> > > > > > our thin client implementation. > > > > > > > >> > > > > > I've looked at our current implementation and ha= ve > > > some > > > > > > > >> proposals > > > > > > > >> > to > > > > > > > >> > > > > > support transactions: > > > > > > > >> > > > > > > > > > > > > >> > > > > > Add new operations to thin client protocol: > > > > > > > >> > > > > > > > > > > > > >> > > > > > OP_TX_GET, 4000, Get current transaction for > > > client > > > > > > > >> connection > > > > > > > >> > > > > > OP_TX_START, 4001, Start a new transaction > > > > > > > >> > > > > > OP_TX_COMMIT, 4002, Commit transaction > > > > > > > >> > > > > > OP_TX_ROLLBACK, 4003, Rollback transaction > > > > > > > >> > > > > > OP_TX_CLOSE, 4004, Close transaction > > > > > > > >> > > > > > > > > > > > > >> > > > > > From the client side (java) new interfaces will = be > > > > added: > > > > > > > >> > > > > > > > > > > > > >> > > > > > public interface ClientTransactions { > > > > > > > >> > > > > > public ClientTransaction txStart(); > > > > > > > >> > > > > > public ClientTransaction > > > > > txStart(TransactionConcurrency > > > > > > > >> > > > concurrency, > > > > > > > >> > > > > > TransactionIsolation isolation); > > > > > > > >> > > > > > public ClientTransaction > > > > > txStart(TransactionConcurrency > > > > > > > >> > > > concurrency, > > > > > > > >> > > > > > TransactionIsolation isolation, long timeout, in= t > > > > txSize); > > > > > > > >> > > > > > public ClientTransaction tx(); // Get curren= t > > > > > connection > > > > > > > >> > > > transaction > > > > > > > >> > > > > > public ClientTransactions withLabel(String > lb); > > > > > > > >> > > > > > } > > > > > > > >> > > > > > > > > > > > > >> > > > > > public interface ClientTransaction extends > > > > AutoCloseable { > > > > > > > >> > > > > > public IgniteUuid xid(); // Do we need it? > > > > > > > >> > > > > > public TransactionIsolation isolation(); > > > > > > > >> > > > > > public TransactionConcurrency concurrency(); > > > > > > > >> > > > > > public long timeout(); > > > > > > > >> > > > > > public String label(); > > > > > > > >> > > > > > > > > > > > > >> > > > > > public void commit(); > > > > > > > >> > > > > > public void rollback(); > > > > > > > >> > > > > > public void close(); > > > > > > > >> > > > > > } > > > > > > > >> > > > > > > > > > > > > >> > > > > > From the server side, I think as a first step > (while > > > > > > > >> transactions > > > > > > > >> > > > > > suspend/resume is not fully implemented) we can > use > > > the > > > > > same > > > > > > > >> > approach > > > > > > > >> > > > as > > > > > > > >> > > > > > for JDBC: add a new worker to each > > > ClientRequestHandler > > > > > and > > > > > > > >> process > > > > > > > >> > > > > > requests by this worker if the transaction is > > started > > > > > > > >> explicitly. > > > > > > > >> > > > > > ClientRequestHandler is bound to client > connection, > > so > > > > > there > > > > > > > >> will > > > > > > > >> > be > > > > > > > >> > > > 1:1 > > > > > > > >> > > > > > relation between client connection and thread, > which > > > > > process > > > > > > > >> > > operations > > > > > > > >> > > > > in > > > > > > > >> > > > > > a transaction. > > > > > > > >> > > > > > > > > > > > > >> > > > > > Also, there is a couple of issues I want to > discuss: > > > > > > > >> > > > > > > > > > > > > >> > > > > > We have overloaded method txStart with a differe= nt > > set > > > > of > > > > > > > >> > arguments. > > > > > > > >> > > > Some > > > > > > > >> > > > > > of the arguments may be missing. To pass argumen= ts > > > with > > > > > > > >> OP_TX_START > > > > > > > >> > > > > > operation we have the next options: > > > > > > > >> > > > > > * Serialize full set of arguments and use some > > value > > > > for > > > > > > > >> missing > > > > > > > >> > > > > > arguments. For example -1 for int/long types and > > null > > > > for > > > > > > > string > > > > > > > >> > > type. > > > > > > > >> > > > We > > > > > > > >> > > > > > can't use 0 for int/long types since 0 it's a > valid > > > > value > > > > > > for > > > > > > > >> > > > > concurrency, > > > > > > > >> > > > > > isolation and timeout arguments. > > > > > > > >> > > > > > * Serialize arguments as a collection of > > > property-value > > > > > > pairs > > > > > > > >> > (like > > > > > > > >> > > > it's > > > > > > > >> > > > > > implemented now for CacheConfiguration). In this > > case > > > > only > > > > > > > >> > explicitly > > > > > > > >> > > > > > provided arguments will be serialized. > > > > > > > >> > > > > > Which way is better? The simplest solution is to > use > > > the > > > > > > first > > > > > > > >> > option > > > > > > > >> > > > > and I > > > > > > > >> > > > > > want to use it if there were no objections. > > > > > > > >> > > > > > > > > > > > > >> > > > > > Do we need transaction id (xid) on the client > side? > > > > > > > >> > > > > > If yes, we can pass xid along with OP_TX_COMMIT, > > > > > > > OP_TX_ROLLBACK, > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the server and do > > > > > additional > > > > > > > >> check > > > > > > > >> > on > > > > > > > >> > > > the > > > > > > > >> > > > > > server side (current transaction id for connecti= on > > =3D=3D > > > > > > > >> transaction > > > > > > > >> > id > > > > > > > >> > > > > passed > > > > > > > >> > > > > > from client side). This, perhaps, will protect > > clients > > > > > > against > > > > > > > >> some > > > > > > > >> > > > > errors > > > > > > > >> > > > > > (for example when client try to commit outdated > > > > > > transaction). > > > > > > > >> But > > > > > > > >> > > > > > currently, we don't have data type IgniteUuid in > > thin > > > > > client > > > > > > > >> > > protocol. > > > > > > > >> > > > Do > > > > > > > >> > > > > > we need to add it too? > > > > > > > >> > > > > > Also, we can pass xid as a string just to inform > the > > > > > client > > > > > > > and > > > > > > > >> do > > > > > > > >> > > not > > > > > > > >> > > > > pass > > > > > > > >> > > > > > it back to the server with commit/rollback > > operation. > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick client wor= ks > > > this > > > > > way > > > > > > as > > > > > > > >> far > > > > > > > >> > > as I > > > > > > > >> > > > > > know). > > > > > > > >> > > > > > > > > > > > > >> > > > > > What do you think? > > > > > > > >> > > > > > > > > > > > > >> > > > > > =D1=81=D1=80, 7 =D0=BC=D0=B0=D1=80. 2018 =D0=B3.= =D0=B2 16:22, Vladimir Ozerov < > > > > > > > >> vozerov@gridgain.com > > > > > > > >> > >: > > > > > > > >> > > > > > > > > > > > > >> > > > > > > We already have transactions support in JDBC > > driver > > > in > > > > > TX > > > > > > > SQL > > > > > > > >> > > branch > > > > > > > >> > > > > > > (ignite-4191). Currently it is implemented > through > > > > > > separate > > > > > > > >> > thread, > > > > > > > >> > > > > which > > > > > > > >> > > > > > > is not that efficient. Ideally we need to fini= sh > > > > > > decoupling > > > > > > > >> > > > > transactions > > > > > > > >> > > > > > > from threads. But alternatively we can change > the > > > > logic > > > > > on > > > > > > > >> how we > > > > > > > >> > > > > assign > > > > > > > >> > > > > > > thread ID to specific transaction and > > "impersonate" > > > > thin > > > > > > > >> client > > > > > > > >> > > > worker > > > > > > > >> > > > > > > threads when serving requests from multiple > users. > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM, Denis Magda < > > > > > > > >> dmagda@apache.org> > > > > > > > >> > > > > wrote: > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Here is an original discussion with a > reference > > to > > > > the > > > > > > > JIRA > > > > > > > >> > > ticket: > > > > > > > >> > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble > > > . > > > > > > > >> > > > > > > > > > > > > > > com/Re-Transaction-operations-using-the-Ignite-Thin-Client- > > > > > > > >> > > > > > > > Protocol-td25914.html > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > -- > > > > > > > >> > > > > > > > Denis > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy > > Setrakyan > > > < > > > > > > > >> > > > > > dsetrakyan@apache.org > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > wrote: > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we have a design > > > > proposal > > > > > > for > > > > > > > >> > > > transaction > > > > > > > >> > > > > > > > support > > > > > > > >> > > > > > > > > in thin clients. Do you mind taking this > > > > initiative > > > > > > and > > > > > > > >> > > creating > > > > > > > >> > > > an > > > > > > > >> > > > > > IEP > > > > > > > >> > > > > > > > on > > > > > > > >> > > > > > > > > Wiki? > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > D. > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy > > > > Govorukhin < > > > > > > > >> > > > > > > > > dmitriy.govorukhin@gmail.com> wrote: > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > Hi, Igniters. > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > I've seen a lot of discussions about thi= n > > > client > > > > > and > > > > > > > >> binary > > > > > > > >> > > > > > protocol, > > > > > > > >> > > > > > > > > but I > > > > > > > >> > > > > > > > > > did not hear anything about transactions > > > > support. > > > > > Do > > > > > > > we > > > > > > > >> > have > > > > > > > >> > > > some > > > > > > > >> > > > > > > draft > > > > > > > >> > > > > > > > > for > > > > > > > >> > > > > > > > > > this purpose? > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > As I understand we have several problems= : > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > - thread and transaction have hard > > related > > > > (we > > > > > > use > > > > > > > >> > > > > thread-local > > > > > > > >> > > > > > > > > variable > > > > > > > >> > > > > > > > > > and thread name) > > > > > > > >> > > > > > > > > > - we can process only one transaction > at > > > the > > > > > same > > > > > > > >> time > > > > > > > >> > in > > > > > > > >> > > > one > > > > > > > >> > > > > > > thread > > > > > > > >> > > > > > > > > (it > > > > > > > >> > > > > > > > > > mean we need hold thread per client. = If > > > > connect > > > > > > 100 > > > > > > > >> thin > > > > > > > >> > > > > clients > > > > > > > >> > > > > > > to > > > > > > > >> > > > > > > > 1 > > > > > > > >> > > > > > > > > > server node, then need to hold 100 > thread > > > on > > > > > the > > > > > > > >> server > > > > > > > >> > > > side) > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > Let's discuss how we can implement > > > transactions > > > > > for > > > > > > > the > > > > > > > >> > thin > > > > > > > >> > > > > > client. > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > -- > > > > > > > >> > > > > Sergey Kozlov > > > > > > > >> > > > > GridGain Systems > > > > > > > >> > > > > www.gridgain.com > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > -- > > > > > > > >> > Sergey Kozlov > > > > > > > >> > GridGain Systems > > > > > > > >> > www.gridgain.com > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --000000000000bb6ac8058587f0c5--