From dev-return-46004-apmail-ignite-dev-archive=ignite.apache.org@ignite.apache.org Mon May 20 11:21:16 2019 Return-Path: X-Original-To: apmail-ignite-dev-archive@minotaur.apache.org Delivered-To: apmail-ignite-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by minotaur.apache.org (Postfix) with SMTP id A3C6F19541 for ; Mon, 20 May 2019 11:21:15 +0000 (UTC) Received: (qmail 26958 invoked by uid 500); 20 May 2019 11:21:14 -0000 Delivered-To: apmail-ignite-dev-archive@ignite.apache.org Received: (qmail 26926 invoked by uid 500); 20 May 2019 11:21:14 -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 26896 invoked by uid 99); 20 May 2019 11:21:09 -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; Mon, 20 May 2019 11:21:09 +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 A4C89C1F41 for ; Mon, 20 May 2019 11:21:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FROM_EXCESS_BASE64=0.105, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ZjhVRmhrh2HN for ; Mon, 20 May 2019 11:21:04 +0000 (UTC) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id AAB91610B4 for ; Mon, 20 May 2019 11:21:03 +0000 (UTC) Received: by mail-oi1-f179.google.com with SMTP id f4so9682520oib.4 for ; Mon, 20 May 2019 04:21:03 -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 :content-transfer-encoding; bh=ERxSNPalVFkZcMlARhS6ghoZmtbS6rE+nm0Qsgqpvhs=; b=YfmkAapF1VKDP4wG1jXP61T7bz4qJkqDhfCwhv+h5akJOuL9Piy1TBTEpDV9j722cl ZEj+a0q9sttdo0rNKHefafviQa6+b583IcRP9jn+BdDSdJfO6TuzCLIUDLi+ORiM7qr+ L9e1fEQFUPcSUYot9Po7t27U/Go2yrI/fY/7u19/U3ogSe21LWK0L+oWnas6lmj6oMYY /n0lG/cqNYH7B/jVZ4crBIEb1PjXFaHZDpSw2eyRRvjpqioWWyrFWuXKPzfUX04KqLOT hdedCQr896dyav7+dW4eCx1sAP2tvNBvNQ9J7NUeCIdCFOSqsxXfz+iiq6gKP3/eN9wR uVzQ== 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:content-transfer-encoding; bh=ERxSNPalVFkZcMlARhS6ghoZmtbS6rE+nm0Qsgqpvhs=; b=ljUeNxyDjtQiDwPPjfYOm8jCDrrCxmb9TikbDzs0unGbLm6GCw331MBWFnJ9S5zHxX CxRKpgOy+X2Gq/sFvYXIWJmjpogy8wtzdZ30gKKVNtEyBv3eAB25+DCk/V2i57qr7rDh surNz5ZmHm00dlerEx2T+8+Av7UB1Sj74BPAfqcf9MrPu4P+SQxNK6L/Qeq8ni6TLdro cnpyQQeM42qkjcg7DB9ifS8php6Qw2bawnv4jhL1xkG9R47TK+Dp4iZ0wD0HqJ6+7LS6 qqVQ2A5TNwcJ7zRsuolc/Nd67KitWxvrQHGqMcG2l5CxVDjM0I3Zn9FGC5pEj2kRonuR hbKA== X-Gm-Message-State: APjAAAVfUOVJweeOK28lpoM9gLfZUMc6KJXVyidqCsNP+GDH5UNjp0q2 VrVcidr63nPDieY6Jd1ng9JEnsJdgslWT5Pcsgud0g== X-Google-Smtp-Source: APXvYqznXfEAvhqBBIUHVH11DdBXHWkzgL21GEThL3N+Wcd1Ab0loHBJSSH7MR4p1zNuw8RL5h63pj0FjXwsIC6BZdk= X-Received: by 2002:aca:5708:: with SMTP id l8mr21054163oib.68.1558351255185; Mon, 20 May 2019 04:20:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?0J/QsNCy0LvRg9GF0LjQvSDQmNCy0LDQvQ==?= Date: Mon, 20 May 2019 14:20:43 +0300 Message-ID: Subject: Re: Thin client: transactions support To: dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Igor, Alex, Regarding point 1. I must say that SQL vendors usually allow to configure default timeouts and a transaction isolation on a server side. E.g. in MySQL you can do a following: set local tx_isolation =3D -- per SQL client session (usually physical network connection) set global tx_isolation =3D -- global settings, all clients (which does not override it) are affected So, if it is a standard practice why should do it differently? If it is not, we can continue discussion. Do we have some examples following opposite way (client-wide default setting)? =D0=BF=D0=BD, 20 =D0=BC=D0=B0=D1=8F 2019 =D0=B3. =D0=B2 13:50, Igor Sapego = : > > 1. In my opinion, having client-specific transaction parameters is expect= ed > for > client when have different arguments depending on server seems unexpected > and can lead to hard-to-debug bugs and issues when updating from old to n= ew > server versions. Also it goes against common practice with arguments of t= hin > client and thus, may be even more unexpected. > > I believe that if we want to add ability to client to adopt some server's > defaults > we should implement it as separate feature, and it should not be a defaul= t > behaviour for client, user should explicitly state that they want this > behaviour, > so it won't be unexpected for them. > > 3. "Flags" field looks like a good solution to me. > > Best Regards, > Igor > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov > wrote: > > > Hi, Igor > > > > 1. I think it's better to have the ability to configure transaction > > parameters (for example configure default timeout for all clients) on > > server-side, then don't have such ability and always use some predefine= d > > client-side values (which can be different for different client > > implementations). At least default timeout is more server specific then > > client specific parameter since it can affect server-side processes (PM= E > > for example). > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be included to e= ach > > cache operation under a transaction. And it almost will not simplify se= rver > > code. Also, thin clients don't know how to deal with IgniteUuid now, th= ere > > is no such entity in the protocol, there are no described rules on how = to > > convert it to a string. For monitoring/debugging purposes we should hav= e > > the same presentation of this entity on server and client sides. I thin= k if > > we need to know real tx id on the client side it's better to additional= ly > > include this value to OP_TX_START response (we also can serialize it as= a > > string to avoid introducing new entity on client side) or create a new > > operation to explicitly request tx id (for example OP_TX_INFO). > > > > 3. Make sense, we can reuse deprecated "flags" field (undeprecate it), > > which is included now to each cache operation. > > > > > > =D0=BF=D1=82, 17 =D0=BC=D0=B0=D1=8F 2019 =D0=B3. =D0=B2 18:49, Igor Sap= ego : > > > > > Hi, > > > > > > I had a look at IEP and have several comments: > > > > > > 1. Why would one want to use to use server's default values for > > Concurrency > > > or Isolation? > > > I believe, client should have its own defaults which should be explic= itly > > > documented, so that > > > behaviour of transactions will not depend on the server node it was > > routed > > > to. The same goes > > > for timeout. > > > > > > 2. Not sure about transaction ID represented by int. Why not to use > > > IgniteUuid? It should simplify > > > server code. Also it may help with monitoring/debugging if thin clien= ts > > and > > > server nodes use the > > > same identifier for transactions. It does not seem as a big overhead = to > > me > > > either. > > > > > > 3. Maybe it makes sense to add "In transaction" boolean flag to cache > > > operation request header > > > to avoid bloating message size in non-affected scenarios. > > > > > > Best Regards, > > > Igor > > > > > > > > > On Mon, May 13, 2019 at 1:58 PM Alex Plehanov > > > wrote: > > > > > > > Hi, Ivan. > > > > > > > > Thanks for your comments. > > > > > > > > 1. Transaction id in thin client protocol it's just a tx counter fo= r > > the > > > > current connection. It's not related to GridCacheVersion. If we wan= t to > > > > know GridCacheVersion on the client side, I think we should introdu= ce a > > > new > > > > type of operation (for example OP_TX_INFO). > > > > 2. Error handling is already provided by thin client protocol, even= in > > > case > > > > of empty response. Of course, the client will know if there is a > > failure > > > > occurred during OP_TX_END operation. > > > > 3. AFAIK some of thin client implementations already send requests = and > > > > process responses in an async way (.NET for example). As for java t= hin > > > > client, in the current implementation channel is locked exclusively > > > before > > > > request send and until the response is processed. I have some ideas > > about > > > > how to fix this (split send/receive process into two different part= s > > and > > > > acquire locks for this parts separately or create futures on reques= t > > sent > > > > and complete it after processing the response in a dedicated thread= ), > > > I've > > > > created ticket [1] for this issue and will try to implement prototy= pe > > in > > > a > > > > couple of days. > > > > > > > > About suspend/resume, yes, on server-side we should resume tx befor= e > > each > > > > transactional cache operation and suspend the tx after the operatio= n. > > In > > > my > > > > opinion, suspend/resume approach have several advantages over appro= ach > > > with > > > > explicit tx id argument: > > > > - Introducing explicit tx id argument for cache operations leads to= a > > > > significant API change > > > > - It's not clear how to use it together with current (tx-per-thread= ) > > > > approach (for example, what if a thread is already held transaction= and > > > > someone call cache operation with explicit tx id?) > > > > - Suspend/resume feature will also be useful for thick clients > > > > - Suspend/resume functionality is already partially implemented (fo= r > > > > optimistic transactions only) > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11685 > > > > > > > > =D0=BF=D1=82, 3 =D0=BC=D0=B0=D1=8F 2019 =D0=B3. =D0=B2 08:10, =D0= =9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD : > > > > > > > > > Hi Alex, > > > > > > > > > > I went through IEP [1] and I have a couple of questions: > > > > > 1. What is going to be used as transaction id? In a described > > protocol > > > > > I see an int field for it. Should not it be GridCacheVersion > > > > > corresponding to IgniteInternalTx#xidVersion? > > > > > 2. OP_TX_END message assumes an empty response, but I think that > > > > > errors during tx finish are possible and should be returned in a > > > > > response. > > > > > 3. In IEP it is stated that async processing of lock operations > > should > > > > > be introduced on a client side to enable concurrent operations fr= om > > > > > different client threads. Do you have an idea how to achieve it? > > > > > > > > > > Also, a bit about a suspend/resume trait. I tried to think about = it > > > > > leaving away an existing transactions implementation in Ignite. A= s I > > > > > understood we are going to resume a tx before each cache operatio= n in > > > > > the tx and resume the tx after the operation. All this to make an > > > > > executing thread available for other operations (e.g. in other tx= s). > > > > > From the first glance it seems like an inversed logic. A > > > > > straightforward way is to execute a cache operation within a > > > > > particular transaction defined as an explicit tx id argument (e.g= . > > > > > cache.put(key, value, txid)). Can we do so? > > > > > > > > > > And leaving for now thin client API. I cannot say that one propos= ed > > in > > > > > IEP is good or bad. I can only say that it ressembles current thi= ck > > > > > client API. And perhaps it should not. I think that we should > > consider > > > > > similar APIs provided by other vendors and keep in mind that we h= ave > > a > > > > > bunch of client implementations for different languages. I suppos= e > > > > > that we can return to it a little bit later. And I hope that we w= ill > > > > > do it. > > > > > > > > > > [1] > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3= A+transactions+support > > > > > > > > > > =D0=B2=D1=82, 30 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 13:24, A= lex Plehanov > >: > > > > > > > > > > > > Hello, Igniters! > > > > > > > > > > > > I've update IEP [1] and implement PoC according to new approach > > > > (multiple > > > > > > concurrent transactions per connection). > > > > > > But to move forward another feature need to be implemented: > > > > > suspend/resume > > > > > > for pessimistic transactions (IGNITE-5714 [2]). Implementation = of > > > > > > suspend/resume is ready now and ticket in 'Patch available' sta= tus. > > > Can > > > > > any > > > > > > transactions expert help with review of IGNITE-5714? > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3= A+transactions+support > > > > > > [2]: https://issues.apache.org/jira/browse/IGNITE-5714 > > > > > > > > > > > > =D1=87=D1=82, 4 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 11:32, = Alex Plehanov > >: > > > > > > > > > > > > > Vladimir, > > > > > > > > > > > > > > Ok, then I will rewrite IEP in the near future. > > > > > > > > > > > > > > =D1=87=D1=82, 4 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 11:14= , Vladimir Ozerov < > > vozerov@gridgain.com > > > >: > > > > > > > > > > > > > >> Hi Alex, > > > > > > >> > > > > > > >> I think we should be able to handle many transactions throug= h a > > > > single > > > > > > >> connection. This will make our protocol and client > > implementations > > > > > much > > > > > > >> more efficient, and simplicity from developer's perspective = is > > not > > > > our > > > > > > >> goal. Consider normal nodes. We have server nodes and client > > > nodes. > > > > > You > > > > > > >> may > > > > > > >> span whatever number of transactions you need, but all of th= em > > are > > > > > > >> coordinated through a single connection. The same should be > > > > > applicable to > > > > > > >> thin clients. Protocol is already designed to handle this, a= s we > > > > pass > > > > > > >> unique operation ID in order to distinguish one operation fr= om > > > > > another. It > > > > > > >> is true, though, that we will have to introduce a kind of > > > "session" > > > > > > >> concept, and pass additional identifier along with cache > > > operations, > > > > > but > > > > > > >> this doesn't sound like a problem to me. > > > > > > >> > > > > > > >> And provided that currently server-side transactions are bou= nd > > to > > > > > threads > > > > > > >> artificially, I would say that the first step in implementat= ion > > of > > > > > > >> transactions on thin clients should be decoupling server-sid= e > > > > > transactions > > > > > > >> from threads. Without this we will have very inefficient > > > > > implementation, > > > > > > >> when every new client transaction have to spawn a new thread= . > > This > > > > is > > > > > slow > > > > > > >> and introduces high memory pressure on a cluster node. We > > already > > > > work > > > > > > >> this > > > > > > >> way for MVCC transactions which are spawned from JDBC driver= , > > and > > > > > believe > > > > > > >> me, we do not want to replicated this bad practice to other > > > clients > > > > > :-) > > > > > > >> > > > > > > >> Vladimir. > > > > > > >> > > > > > > >> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov < > > > > > plehanov.alex@gmail.com> > > > > > > >> wrote: > > > > > > >> > > > > > > >> > Guys, so, do we need multiple concurrent transactions per > > > > > connection? > > > > > > >> > > > > > > > >> > There are pros and cons for each approach. Difference betw= een > > > > > > >> approaches: > > > > > > >> > > > > > > > >> > One transaction at a time per connection: > > > > > > >> > - This approach is used in RDBMS world and users got used= to > > it > > > > > > >> > - To use transactions concurrently users need to use > > different > > > > > > >> connections > > > > > > >> > and get these connections via something like a connection = pool > > > > > > >> > - Easy to implement (in fact, PoC is already done) > > > > > > >> > > > > > > > >> > Multiple concurrent transactions per connection: > > > > > > >> > - At least for java thin client, we can implement transac= tion > > > per > > > > > > >> thread > > > > > > >> > approach as implemented now for the thick client (perhaps > > other > > > > thin > > > > > > >> > clients can implement the same abstraction) > > > > > > >> > - There is also protocol change for all cache operations > > needed > > > > (to > > > > > > >> bind > > > > > > >> > cache operation to the transaction) > > > > > > >> > - Significant changes to all implemented clients are need= ed > > > > > > >> > - Implementation on the server side is more complex > > > > > > >> > > > > > > > >> > What do you think? > > > > > > >> > > > > > > > >> > > > > > > > >> > =D0=B2=D1=82, 2 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 16= :29, Alex Plehanov < > > > > plehanov.alex@gmail.com > > > > > >: > > > > > > >> > > > > > > > >> > > Ilya, > > > > > > >> > > > > > > > > >> > > > We should be able to multiplex several transactions us= ing > > a > > > > > single > > > > > > >> > > Client connection. > > > > > > >> > > In this case, we should significantly change cache > > operations > > > > > syntax > > > > > > >> (for > > > > > > >> > > each implemented client), to bind each operation to the > > > > > transaction. > > > > > > >> > > > > > > > > >> > > > I want to also ask if "Number of entries participating= in > > > > > > >> transaction > > > > > > >> > > (may be approximate). 0 - default value." is needed. > > > > > > >> > > I've tried to minimize API changes between thick and thi= n > > > client > > > > > to > > > > > > >> > > simplify move from one to another. It's the only reason. > > But I > > > > > agree > > > > > > >> with > > > > > > >> > > you, the parameter is not very useful. > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > =D0=B2=D1=82, 2 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 = 14:48, Ilya Kasnacheev < > > > > > > >> ilya.kasnacheev@gmail.com>: > > > > > > >> > > > > > > > > >> > >> Hello! > > > > > > >> > >> > > > > > > >> > >> Pavel, I agree with you thorougly. We should be able to > > > > multiplex > > > > > > >> > several > > > > > > >> > >> transactions using a single Client connection. This mea= ns > > > > adding > > > > > > >> > >> Transaction id parameter to every affected cache operat= ion > > / > > > > SQL > > > > > > >> > statement > > > > > > >> > >> (if applicable) to make sure we do cache operations on > > > relevant > > > > > > >> > >> transaction. > > > > > > >> > >> > > > > > > >> > >> This is how other things work in Ignite, such as > > > communication. > > > > > We do > > > > > > >> > not > > > > > > >> > >> open dozens of connections, we multiplex operations > > > > > asynchronously > > > > > > >> > through > > > > > > >> > >> a single connection. > > > > > > >> > >> > > > > > > >> > >> I think that trying to pool Ignite connections will be > > highly > > > > > > >> > >> inconvenient, > > > > > > >> > >> since there is no existing infrastructure for such pool= ing > > > > (like > > > > > > >> there > > > > > > >> > >> exists for JDBC). > > > > > > >> > >> > > > > > > >> > >> I want to also ask if "Number of entries participating = in > > > > > transaction > > > > > > >> > (may > > > > > > >> > >> be approximate). 0 - default value." is needed. Does it > > > > actually > > > > > do > > > > > > >> > >> anything in our tx protocol? Users of existing APIs are > > > already > > > > > > >> confused > > > > > > >> > >> by > > > > > > >> > >> this parameter, if we could get rid of it in thin clien= t > > > > > protocol it > > > > > > >> > would > > > > > > >> > >> be nice clean-up. > > > > > > >> > >> > > > > > > >> > >> Regards, > > > > > > >> > >> -- > > > > > > >> > >> Ilya Kasnacheev > > > > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> =D0=B2=D1=82, 2 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2= 09:55, Pavel Tupitsyn < > > > > ptupitsyn@apache.org > > > > > >: > > > > > > >> > >> > > > > > > >> > >> > Alex, > > > > > > >> > >> > > > > > > > >> > >> > > now we can only support one active transaction per > > > > connection > > > > > > >> > >> > > > > > > > >> > >> > I totally understand server-side and protocol limitat= ions > > > > that > > > > > are > > > > > > >> > >> causing > > > > > > >> > >> > 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 < > > > > > > >> plehanov.alex@gmail.com > > > > > > >> > > > > > > > > >> > >> > 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%3= A+transactions+support > > > > > > >> > >> > > > > > > > > >> > >> > > > > > > > > >> > >> > > =D1=87=D1=82, 28 =D0=BC=D0=B0=D1=80. 2019 =D0=B3. = =D0=B2 14:33, Dmitriy Pavlov < > > > > > dpavlov@apache.org > > > > > > >> >: > > > > > > >> > >> > > > > > > > > >> > >> > > > 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 a= sk > > > 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 < > > > > > > >> > plehanov.alex@gmail.com > > > > > > >> > >> >: > > > > > > >> > >> > > > > > > > > > >> > >> > > > > Vladimir, > > > > > > >> > >> > > > > > > > > > > >> > >> > > > > About current tx: ok, then we don't need tx() > > method > > > in > > > > > the > > > > > > >> > >> interface > > > > > > >> > >> > > at > > > > > > >> > >> > > > > all (the same cached transaction info user can > > store > > > by > > > > > > >> > himself). > > > > > > >> > >> > > > > > > > > > > >> > >> > > > > About decoupling transactions from threads on t= he > > > > server > > > > > > >> side: > > > > > > >> > for > > > > > > >> > >> > now, > > > > > > >> > >> > > > we > > > > > > >> > >> > > > > can start with thread-per-connection approach (= we > > > only > > > > > can > > > > > > >> > support > > > > > > >> > >> > one > > > > > > >> > >> > > > > active transaction per connection, see below, s= o we > > > > need > > > > > one > > > > > > >> > >> > additional > > > > > > >> > >> > > > > dedicated thread for each connection with activ= e > > > > > > >> 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 serve= r > > > side. > > > > > > >> > >> > > > > In any case, we can't support concurrent > > transactions > > > > per > > > > > > >> > >> connection > > > > > > >> > >> > on > > > > > > >> > >> > > > > the client side without fundamental changes to = the > > > > > current > > > > > > >> > >> protocol > > > > > > >> > >> > > > (cache > > > > > > >> > >> > > > > operation doesn't bound to transaction or threa= d > > and > > > > the > > > > > > >> server > > > > > > >> > >> > doesn't > > > > > > >> > >> > > > > know which thread on the client side do this ca= che > > > > > > >> operation). > > > > > > >> > In > > > > > > >> > >> my > > > > > > >> > >> > > > > opinion, if a user wants to use concurrent > > > > transactions, > > > > > he > > > > > > >> must > > > > > > >> > >> use > > > > > > >> > >> > > > > different connections from a connection pool. > > > > > > >> > >> > > > > > > > > > > >> > >> > > > > About semantics of suspend/resume on the > > client-side: > > > > > it's > > > > > > >> > >> absolutely > > > > > > >> > >> > > > > 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, Vladimir Ozerov < > > > > > > >> > >> vozerov@gridgain.com>: > > > > > > >> > >> > > > > > > > > > > >> > >> > > > > > Hi Alex, > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > My comments was only about the protocol. Gett= ing > > > > > current > > > > > > >> info > > > > > > >> > >> about > > > > > > >> > >> > > > > > transaction should be handled by the client > > itself. > > > > It > > > > > is > > > > > > >> not > > > > > > >> > >> > > protocl's > > > > > > >> > >> > > > > > concern. Same about other APIs and behavior i= n > > case > > > > > another > > > > > > >> > >> > > transaction > > > > > > >> > >> > > > > is > > > > > > >> > >> > > > > > attempted from the same thread. > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > Putting protocol aside, transaction support i= s > > > > > complicated > > > > > > >> > >> matter. > > > > > > >> > >> > I > > > > > > >> > >> > > > > would > > > > > > >> > >> > > > > > propose to route through IEP and wide communi= ty > > > > > > >> discussion. We > > > > > > >> > >> need > > > > > > >> > >> > > to > > > > > > >> > >> > > > > > review API and semantics very carefully, taki= ng > > > > > > >> 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 Plehano= v < > > > > > > >> > >> > > > plehanov.alex@gmail.com> > > > > > > >> > >> > > > > > wrote: > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > > Vladimir, what if we want to get current > > > > transaction > > > > > info > > > > > > >> > >> (tx() > > > > > > >> > >> > > > > method)? > > > > > > >> > >> > > > > > > > > > > > > >> > >> > > > > > > Does close() method mapped to TX_END(rollba= ck)? > > > > > > >> > >> > > > > > > > > > > > > >> > >> > > > > > > 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. U= se > > > some > > > > > unique > > > > > > >> > per > > > > > > >> > >> > > > > connection > > > > > > >> > >> > > > > > id > > > > > > >> > >> > > > > > > (integer, simple counter) for identifying t= he > > > > > > >> transaction on > > > > > > >> > >> > > > > > > commit/rollback message. The client gets th= is > > id > > > > > from the > > > > > > >> > >> server > > > > > > >> > >> > > 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? Sho= uld > > we > > > > > end the > > > > > > >> > old > > > > > > >> > >> > > > > transaction > > > > > > >> > >> > > > > > > implicitly (rollback) or throw an exception= to > > > the > > > > > > >> client? > > > > > > >> > In > > > > > > >> > >> my > > > > > > >> > >> > > > > opinion, > > > > > > >> > >> > > > > > > the first option is better. For example, if= we > > > got > > > > a > > > > > > >> > >> previously > > > > > > >> > >> > > used > > > > > > >> > >> > > > > > > connection from the connection pool, we sho= uld > > > not > > > > > worry > > > > > > >> > about > > > > > > >> > >> > any > > > > > > >> > >> > > > > > > uncompleted transaction started by the prev= ious > > > > 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 d= o > > 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. Would= n't > > it > > > > be > > > > > > >> enough > > > > > > >> > to > > > > > > >> > >> > have > > > > > > >> > >> > > > > only > > > > > > >> > >> > > > > > > two? > > > > > > >> > >> > > > > > > > > > > > > > > >> > >> > > > > > > > > START - accepts optional parameters, > > returns > > > > > > >> transaction > > > > > > >> > >> info > > > > > > >> > >> > > > > > > > > END - provides commit flag, returns voi= d > > > > > > >> > >> > > > > > > > > > > > > > > >> > >> > > > > > > > > Vladimir. > > > > > > >> > >> > > > > > > > > > > > > > > >> > >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex > > > Plehanov < > > > > > > >> > >> > > > > > plehanov.alex@gmail.com > > > > > > >> > >> > > > > > > > > > > > > > >> > >> > > > > > > > > wrote: > > > > > > >> > >> > > > > > > > > > > > > > > >> > >> > > > > > > > >> Sergey, yes, the close is something li= ke > > > > silent > > > > > > >> > rollback. > > > > > > >> > >> > But > > > > > > >> > >> > > we > > > > > > >> > >> > > > > can > > > > > > >> > >> > > > > > > > >> also implement this on the client side= , > > just > > > > > using > > > > > > >> > >> rollback > > > > > > >> > >> > > and > > > > > > >> > >> > > > > > > ignoring > > > > > > >> > >> > > > > > > > >> errors in the response. > > > > > > >> > >> > > > > > > > >> > > > > > > >> > >> > > > > > > > >> =D1=81=D1=80, 27 =D0=BC=D0=B0=D1=80. 2= 019 =D0=B3. =D0=B2 00: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 > > > > > > >> > >> to > > > > > > >> > >> > > free > > > > > > >> > >> > > > > > some > > > > > > >> > >> > > > > > > > >> > resources on server node(s)or just d= o on > > > > > client > > > > > > >> > started > > > > > > >> > >> > TX? > > > > > > >> > >> > > > > > > > >> > > > > > > > >> > >> > > > > > > > >> > > > > > > > >> > >> > > > > > > > >> > > > > > > > >> > >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Ale= x > > > > > 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 d= o > > > > nothing > > > > > if > > > > > > >> the > > > > > > >> > >> > > > transaction > > > > > > >> > >> > > > > > is > > > > > > >> > >> > > > > > > > >> already > > > > > > >> > >> > > > > > > > >> > > committed). I think we should supp= ort > > > > > > >> > >> try-with-resource > > > > > > >> > >> > > > > > semantics > > > > > > >> > >> > > > > > > in > > > > > > >> > >> > > > > > > > >> the > > > > > > >> > >> > > > > > > > >> > > thin client and OP_TX_CLOSE will b= e > > > useful > > > > > here. > > > > > > >> > >> > > > > > > > >> > > > > > > > > >> > >> > > > > > > > >> > > Nikolay, suspend/resume didn't wor= k > > yet > > > > for > > > > > > >> > >> pessimistic > > > > > > >> > >> > > > > > > > transactions. > > > > > > >> > >> > > > > > > > >> > Also, > > > > > > >> > >> > > > > > > > >> > > the main goal of suspend/resume > > > operations > > > > > is to > > > > > > >> > >> support > > > > > > >> > >> > > > > > > transaction > > > > > > >> > >> > > > > > > > >> > > passing between threads. In the th= in > > > > > client, the > > > > > > >> > >> > > transaction > > > > > > >> > >> > > > > is > > > > > > >> > >> > > > > > > > bound > > > > > > >> > >> > > > > > > > >> to > > > > > > >> > >> > > > > > > > >> > > the client connection, not client > > > thread. > > > > I > > > > > > >> think > > > > > > >> > >> > passing > > > > > > >> > >> > > a > > > > > > >> > >> > > > > > > > >> transaction > > > > > > >> > >> > > > > > > > >> > > between different client connectio= ns > > 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 co= de > > for > > > > > > >> SAVEPOINT > > > > > > >> > >> > > operation > > > > > > >> > >> > > > > > which > > > > > > >> > >> > > > > > > > >> very > > > > > > >> > >> > > > > > > > >> > > > useful > > > > > > >> > >> > > > > > > > >> > > > > to understand where transactio= n > > has > > > > been > > > > > > >> rolled > > > > > > >> > >> back > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > >> > >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 P= M > > 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 implementati= on. > > > > > > >> > >> > > > > > > > >> > > > > > I've looked at our current > > > > > implementation > > > > > > >> and > > > > > > >> > >> have > > > > > > >> > >> > > > some > > > > > > >> > >> > > > > > > > >> proposals > > > > > > >> > >> > > > > > > > >> > to > > > > > > >> > >> > > > > > > > >> > > > > > support transactions: > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > > >> > >> > > > > > > > >> > > > > > Add new operations to thin > > client > > > > > > >> protocol: > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > > >> > >> > > > > > > > >> > > > > > OP_TX_GET, 4000, Get cur= rent > > > > > > >> transaction > > > > > > >> > >> for > > > > > > >> > >> > > > client > > > > > > >> > >> > > > > > > > >> connection > > > > > > >> > >> > > > > > > > >> > > > > > OP_TX_START, 4001, Start= a > > new > > > > > > >> > transaction > > > > > > >> > >> > > > > > > > >> > > > > > OP_TX_COMMIT, 4002, Comm= it > > > > > 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 isolati= on); > > > > > > >> > >> > > > > > > > >> > > > > > public ClientTransaction > > > > > > >> > >> > > > > > txStart(TransactionConcurrency > > > > > > >> > >> > > > > > > > >> > > > concurrency, > > > > > > >> > >> > > > > > > > >> > > > > > TransactionIsolation isolati= on, > > > long > > > > > > >> timeout, > > > > > > >> > >> int > > > > > > >> > >> > > > > txSize); > > > > > > >> > >> > > > > > > > >> > > > > > public ClientTransaction > > tx(); > > > > // > > > > > Get > > > > > > >> > >> current > > > > > > >> > >> > > > > > connection > > > > > > >> > >> > > > > > > > >> > > > transaction > > > > > > >> > >> > > > > > > > >> > > > > > public ClientTransaction= s > > > > > > >> > withLabel(String > > > > > > >> > >> > lb); > > > > > > >> > >> > > > > > > > >> > > > > > } > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > > >> > >> > > > > > > > >> > > > > > public interface > > ClientTransaction > > > > > extends > > > > > > >> > >> > > > > AutoCloseable { > > > > > > >> > >> > > > > > > > >> > > > > > public IgniteUuid xid();= // > > Do > > > > we > > > > > need > > > > > > >> > it? > > > > > > >> > >> > > > > > > > >> > > > > > public TransactionIsolat= ion > > > > > > >> isolation(); > > > > > > >> > >> > > > > > > > >> > > > > > public > > TransactionConcurrency > > > > > > >> > >> concurrency(); > > > > > > >> > >> > > > > > > > >> > > > > > public long timeout(); > > > > > > >> > >> > > > > > > > >> > > > > > public String label(); > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > > >> > >> > > > > > > > >> > > > > > public void commit(); > > > > > > >> > >> > > > > > > > >> > > > > > public void rollback(); > > > > > > >> > >> > > > > > > > >> > > > > > public void close(); > > > > > > >> > >> > > > > > > > >> > > > > > } > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > > >> > >> > > > > > > > >> > > > > > From the server side, I thin= k > > 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 t= o > > each > > > > > > >> > >> > > > ClientRequestHandler > > > > > > >> > >> > > > > > and > > > > > > >> > >> > > > > > > > >> process > > > > > > >> > >> > > > > > > > >> > > > > > requests by this worker if t= he > > > > > > >> transaction is > > > > > > >> > >> > > started > > > > > > >> > >> > > > > > > > >> explicitly. > > > > > > >> > >> > > > > > > > >> > > > > > ClientRequestHandler is boun= d 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 > > > > > > >> > >> different > > > > > > >> > >> > > set > > > > > > >> > >> > > > > of > > > > > > >> > >> > > > > > > > >> > arguments. > > > > > > >> > >> > > > > > > > >> > > > Some > > > > > > >> > >> > > > > > > > >> > > > > > of the arguments may be miss= ing. > > > To > > > > > pass > > > > > > >> > >> arguments > > > > > > >> > >> > > > 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 fo= r > > > > int/long > > > > > > >> types > > > > > > >> > >> and > > > > > > >> > >> > > null > > > > > > >> > >> > > > > for > > > > > > >> > >> > > > > > > > string > > > > > > >> > >> > > > > > > > >> > > type. > > > > > > >> > >> > > > > > > > >> > > > We > > > > > > >> > >> > > > > > > > >> > > > > > can't use 0 for int/long typ= es > > > > since 0 > > > > > > >> it's a > > > > > > >> > >> > valid > > > > > > >> > >> > > > > value > > > > > > >> > >> > > > > > > for > > > > > > >> > >> > > > > > > > >> > > > > concurrency, > > > > > > >> > >> > > > > > > > >> > > > > > isolation and timeout argume= nts. > > > > > > >> > >> > > > > > > > >> > > > > > * 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 (x= id) > > on > > > > the > > > > > > >> client > > > > > > >> > >> > side? > > > > > > >> > >> > > > > > > > >> > > > > > If yes, we can pass xid alon= g > > with > > > > > > >> > >> OP_TX_COMMIT, > > > > > > >> > >> > > > > > > > OP_TX_ROLLBACK, > > > > > > >> > >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back = to > > the > > > > > server > > > > > > >> and > > > > > > >> > >> do > > > > > > >> > >> > > > > > additional > > > > > > >> > >> > > > > > > > >> check > > > > > > >> > >> > > > > > > > >> > on > > > > > > >> > >> > > > > > > > >> > > > the > > > > > > >> > >> > > > > > > > >> > > > > > server side (current transac= tion > > > id > > > > > for > > > > > > >> > >> connection > > > > > > >> > >> > > =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 dat= a > > 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 > > > > > > >> > >> works > > > > > > >> > >> > > > 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 transactio= ns > > > > > support in > > > > > > >> > JDBC > > > > > > >> > >> > > driver > > > > > > >> > >> > > > in > > > > > > >> > >> > > > > > TX > > > > > > >> > >> > > > > > > > SQL > > > > > > >> > >> > > > > > > > >> > > branch > > > > > > >> > >> > > > > > > > >> > > > > > > (ignite-4191). Currently i= t is > > > > > > >> implemented > > > > > > >> > >> > through > > > > > > >> > >> > > > > > > separate > > > > > > >> > >> > > > > > > > >> > thread, > > > > > > >> > >> > > > > > > > >> > > > > which > > > > > > >> > >> > > > > > > > >> > > > > > > is not that efficient. Ide= ally > > > we > > > > > need > > > > > > >> to > > > > > > >> > >> finish > > > > > > >> > >> > > > > > > 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 reque= sts > > > 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 th= ink > > we > > > > > have a > > > > > > >> > >> design > > > > > > >> > >> > > > > proposal > > > > > > >> > >> > > > > > > for > > > > > > >> > >> > > > > > > > >> > > > transaction > > > > > > >> > >> > > > > > > > >> > > > > > > > support > > > > > > >> > >> > > > > > > > >> > > > > > > > > in thin clients. Do yo= u > > 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 > > > > > > >> > >> thin > > > > > > >> > >> > > > client > > > > > > >> > >> > > > > > and > > > > > > >> > >> > > > > > > > >> binary > > > > > > >> > >> > > > > > > > >> > > > > > protocol, > > > > > > >> > >> > > > > > > > >> > > > > > > > > but I > > > > > > >> > >> > > > > > > > >> > > > > > > > > > did not hear anythin= g > > > about > > > > > > >> > >> transactions > > > > > > >> > >> > > > > support. > > > > > > >> > >> > > > > > Do > > > > > > >> > >> > > > > > > > we > > > > > > >> > >> > > > > > > > >> > have > > > > > > >> > >> > > > > > > > >> > > > some > > > > > > >> > >> > > > > > > > >> > > > > > > draft > > > > > > >> > >> > > > > > > > >> > > > > > > > > for > > > > > > >> > >> > > > > > > > >> > > > > > > > > > this purpose? > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > > > > > > >> > >> > > > > > > > >> > > > > > > > > > As I understand we h= ave > > > > > 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 > > > > > > >> > >> > > > > > > > >> > > > > > > > >> > >> > > > > > > > >> > > > > > > >> > >> > > > > > > > > > > > > > > >> > >> > > > > > > > > > > > > > >> > >> > > > > > > > > > > > > >> > >> > > > > > > > > > > > >> > >> > > > > > > > > > > >> > >> > > > > > > > > > >> > >> > > > > > > > > >> > >> > > > > > > > >> > >> > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > --=20 Best regards, Ivan Pavlukhin