Hi Pavel, Thank you for the review!
Igniters, Also, I want to bring here a discussion about configuring limit for active transactions per thin client connection. I see two ways to configure such limit: 1. A new system property 2. A new ClientConnectorConfiguration class property. In the current implementation, I've introduced a new system property IGNITE_THIN_MAX_ACTIVE_TX_PER_CONNECTION. Pavel proposes to configure limit via ClientConnectorConfiguration. Such limit is only reliable to thin clients, but ClientConnectorConfiguration is also used for JDBC and ODBC connections as well. A new property in ClientConnectorConfiguration will be useless for JDBC and ODBC (since they use one transaction per connection) and may be confusing. Which way is better, WDYT? чт, 15 авг. 2019 г. в 11:46, Pavel Tupitsyn <ptupit...@apache.org>: > Hi Alex, > > I've checked the patch, protocol changes look good to me. See reply in > Jira. > But we certainly need more eyes on this. > > On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov <plehanov.a...@gmail.com> > wrote: > > > Hi Ivan, > > > > Java thin client doesn't support affinity awareness yet (ticket [1] is in > > progress now), but changes to correctly work with protocol version 1.4.0 > > was made, so java thin client will work properly with 1.4.0 and 1.5.0 > > protocol versions. > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11898 > > > > чт, 15 авг. 2019 г. в 10:23, Павлухин Иван <vololo...@gmail.com>: > > > > > Hi Alex, > > > > > > Could you please elaborate about thin client protocol versioning. As I > > > see 1.5.0 is supposed to be a version supporting transactions. And we > > > already have a version 1.4.0 with affinity awareness support. I > > > forgot, does Java thin client support affinity awareness? Will it work > > > properly if it does not? > > > > > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov <plehanov.a...@gmail.com>: > > > > > > > > Hi Igniters, > > > > > > > > Finally, all dependent tickets are resolved and I've completed the > > > > implementation of thin client transactions support. The patch [1] > > > includes > > > > server-side implementation and java thin client-side implementation. > > > > Changes to thin client protocol and top-level view of implementation > > also > > > > described in IEP [2]. > > > > Can anyone review the patch? > > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-9410 > > > > [2]: > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support > > > > > > > > пн, 27 мая 2019 г. в 13:27, Alex Plehanov <plehanov.a...@gmail.com>: > > > > > > > > > Ivan, > > > > > > > > > > Yes, .NET client has such capability. Pavel Tupitsyn already > mentions > > > it > > > > > in this thread. As far as I understand, in .NET client > implementation > > > to > > > > > dispatch responses dedicated thread is used. > > > > > In a draft implementation of IGNITE-11685 I've used another > approach: > > > each > > > > > request thread can read a response (if lock is acquired by this > > thread > > > > > successfully) and complete a future of its own request or another > > > threads > > > > > request. > > > > > > > > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vololo...@gmail.com>: > > > > > > > > > >> Alex, > > > > >> > > > > >> I am quite curious about async implementations from other clients. > > Is > > > > >> there any design document describing such implementations? Does > .NET > > > > >> client have such capability? > > > > >> > > > > >> Actually, I forgot to finish my previous message. One of my > concerns > > > > >> is that a concurrent response dispatch does not sound as a trivial > > > > >> thing. So, I would like to understand if we already have a good > > > > >> approach for that. If not then I suppose it worth a discussion. > > > > >> > > > > >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov < > plehanov.a...@gmail.com > > >: > > > > >> > > > > > >> > Hi Ivan. > > > > >> > > > > > >> > Thin client transactions support is not only for java thin > client. > > > There > > > > >> > are other clients, some of them already work in async mode. > > > > >> > Ticket IGNITE-11685 already has draft implementation too, but > now > > > it's > > > > >> > based on some changes to java thin client which were made by > > > > >> "transaction > > > > >> > support" implementation. I think this ticket will be ready in a > > > couple > > > > >> of > > > > >> > days after "transaction support" will be merged. And both > patches > > > will > > > > >> be > > > > >> > included in the same release. > > > > >> > > > > > >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван <vololo...@gmail.com > >: > > > > >> > > > > > >> > > Hi Alex, > > > > >> > > > > > > >> > > Regarding a problem with possible deadlock when two concurrent > > > > >> > > transactions from the same client are trying to lock the same > > key > > > and > > > > >> > > an issue [1]. It seems to me that without fixing the issue > [1] a > > > > >> > > client transactions feature is not practical. Everyone who > uses > > a > > > > >> > > client from multiple threads can face a deadlock which is > > > impossible > > > > >> > > to deal with. Or am I missing something here? > > > > >> > > > > > > >> > > One workaround I can imagine is failing a transactions > execution > > > from > > > > >> > > concurrent threads for a first time. > > > > >> > > > > > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685 > > > > >> > > > > > > >> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov < > > > plehanov.a...@gmail.com>: > > > > >> > > > > > > > >> > > > Guys, > > > > >> > > > > > > > >> > > > I've updated the IEP [1]. Please have a look. > > > > >> > > > > > > > >> > > > [1] > > > > >> > > > > > > > >> > > > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support > > > > >> > > > > > > > >> > > > > > > > >> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov < > > > plehanov.a...@gmail.com>: > > > > >> > > > > > > > >> > > > > Ivan, > > > > >> > > > > > > > > >> > > > > Yes, I have plans to do that (at least for java thin > > client). > > > > >> Something > > > > >> > > > > like new class "ClientTransactionConfiguration" inside > > > > >> > > > > "ClientConfiguration". > > > > >> > > > > > > > > >> > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван < > > > vololo...@gmail.com>: > > > > >> > > > > > > > > >> > > > >> Alex, > > > > >> > > > >> > > > > >> > > > >> Are you going to introduce settings specifying default > > values > > > > >> for tx > > > > >> > > > >> concurrency and isolation in client configuration? > > > > >> > > > >> > > > > >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov < > > > > >> plehanov.a...@gmail.com>: > > > > >> > > > >> > > > > > >> > > > >> > Igor, > > > > >> > > > >> > > > > > >> > > > >> > Perhaps we don't really need to use server's default > > values > > > > >> for tx > > > > >> > > > >> > parameters. It's a minor fix and can be easily > > implemented > > > if > > > > >> it > > > > >> > > will be > > > > >> > > > >> > required in the future. > > > > >> > > > >> > I will update IEP tomorrow regarding point 1 and point > 3. > > > > >> > > > >> > Thanks for your feedback. > > > > >> > > > >> > > > > > >> > > > >> > пн, 20 мая 2019 г. в 15:24, Igor Sapego < > > > isap...@apache.org>: > > > > >> > > > >> > > > > > >> > > > >> > > Ivan, > > > > >> > > > >> > > > > > > >> > > > >> > > This may be a good point for a DBMS, but Ignite is > much > > > more > > > > >> than > > > > >> > > > >> just a > > > > >> > > > >> > > DBMS and Ignite client code is not just an SQL query > > > (which > > > > >> > > execution > > > > >> > > > >> > > inherently heavily depends on DBMS). With database > user > > > is > > > > >> > > expecting > > > > >> > > > >> that > > > > >> > > > >> > > server have a lot of control on query execution. But > > with > > > > >> Ignite, > > > > >> > > in > > > > >> > > > >> my > > > > >> > > > >> > > opinion, > > > > >> > > > >> > > user writes generic code including business logic in > > > native > > > > >> > > language > > > > >> > > > >> and > > > > >> > > > >> > > may > > > > >> > > > >> > > expect more deterministic behaviour from a client. > > > > >> > > > >> > > > > > > >> > > > >> > > Also, thick clients do not use server-side defaults. > > > > >> > > > >> > > > > > > >> > > > >> > > Of course, this question is debatable and It's not > > like I > > > > >> 100% > > > > >> > > against > > > > >> > > > >> > > server-side > > > > >> > > > >> > > defaults here, I just suggest to discuss it in more > > > detail. > > > > >> > > > >> > > > > > > >> > > > >> > > Best Regards, > > > > >> > > > >> > > Igor > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > > >> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван < > > > > >> > > vololo...@gmail.com> > > > > >> > > > >> wrote: > > > > >> > > > >> > > > > > > >> > > > >> > > > 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 = <isolation> -- per SQL > > client > > > > >> session > > > > >> > > > >> > > > (usually physical network connection) > > > > >> > > > >> > > > set global tx_isolation = <isolation> -- 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)? > > > > >> > > > >> > > > > > > > >> > > > >> > > > пн, 20 мая 2019 г. в 13:50, Igor Sapego < > > > > >> isap...@apache.org>: > > > > >> > > > >> > > > > > > > > >> > > > >> > > > > 1. In my opinion, having client-specific > > transaction > > > > >> > > parameters is > > > > >> > > > >> > > > expected > > > > >> > > > >> > > > > 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 > > > > >> > > > >> > > > new > > > > >> > > > >> > > > > server versions. Also it goes against common > > practice > > > > >> with > > > > >> > > > >> arguments of > > > > >> > > > >> > > > thin > > > > >> > > > >> > > > > 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 > > > > >> > > > >> > > > default > > > > >> > > > >> > > > > 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 < > > > > >> > > > >> > > plehanov.a...@gmail.com> > > > > >> > > > >> > > > > 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 > > > > >> > > > >> > > > predefined > > > > >> > > > >> > > > > > 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 > > > > >> > > > >> > > > (PME > > > > >> > > > >> > > > > > for example). > > > > >> > > > >> > > > > > > > > > >> > > > >> > > > > > 2. IgniteUuid has 24 bytes length. This tx id > > > needs to > > > > >> be > > > > >> > > > >> included to > > > > >> > > > >> > > > each > > > > >> > > > >> > > > > > cache operation under a transaction. And it > > almost > > > > >> will not > > > > >> > > > >> simplify > > > > >> > > > >> > > > server > > > > >> > > > >> > > > > > code. Also, thin clients don't know how to deal > > > with > > > > >> > > IgniteUuid > > > > >> > > > >> now, > > > > >> > > > >> > > > there > > > > >> > > > >> > > > > > 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 > > > > >> > > > >> > > > have > > > > >> > > > >> > > > > > the same presentation of this entity on server > > and > > > > >> client > > > > >> > > > >> sides. I > > > > >> > > > >> > > > think if > > > > >> > > > >> > > > > > we need to know real tx id on the client side > > it's > > > > >> better to > > > > >> > > > >> > > > additionally > > > > >> > > > >> > > > > > 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. > > > > >> > > > >> > > > > > > > > > >> > > > >> > > > > > > > > > >> > > > >> > > > > > пт, 17 мая 2019 г. в 18:49, Igor Sapego < > > > > >> isap...@apache.org > > > > >> > > >: > > > > >> > > > >> > > > > > > > > > >> > > > >> > > > > > > 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 > > > > >> > > > >> > > > explicitly > > > > >> > > > >> > > > > > > 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 > > > > >> > > > >> > > > clients > > > > >> > > > >> > > > > > 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 < > > > > >> > > > >> > > > plehanov.a...@gmail.com> > > > > >> > > > >> > > > > > > wrote: > > > > >> > > > >> > > > > > > > > > > >> > > > >> > > > > > > > Hi, Ivan. > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > Thanks for your comments. > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > 1. Transaction id in thin client protocol > > it's > > > > >> just a tx > > > > >> > > > >> counter > > > > >> > > > >> > > > for > > > > >> > > > >> > > > > > the > > > > >> > > > >> > > > > > > > current connection. It's not related to > > > > >> > > GridCacheVersion. > > > > >> > > > >> If we > > > > >> > > > >> > > > want to > > > > >> > > > >> > > > > > > > know GridCacheVersion on the client side, I > > > think > > > > >> we > > > > >> > > should > > > > >> > > > >> > > > introduce 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 > > > > >> > > > >> > > > thin > > > > >> > > > >> > > > > > > > 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 > > > > >> > > > >> > > > parts > > > > >> > > > >> > > > > > and > > > > >> > > > >> > > > > > > > acquire locks for this parts separately or > > > create > > > > >> > > futures on > > > > >> > > > >> > > > request > > > > >> > > > >> > > > > > 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 > > > > >> > > > >> > > > prototype > > > > >> > > > >> > > > > > in > > > > >> > > > >> > > > > > > a > > > > >> > > > >> > > > > > > > couple of days. > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > About suspend/resume, yes, on server-side > we > > > should > > > > >> > > resume > > > > >> > > > >> tx > > > > >> > > > >> > > > before > > > > >> > > > >> > > > > > each > > > > >> > > > >> > > > > > > > transactional cache operation and suspend > the > > > tx > > > > >> after > > > > >> > > the > > > > >> > > > >> > > > operation. > > > > >> > > > >> > > > > > In > > > > >> > > > >> > > > > > > my > > > > >> > > > >> > > > > > > > opinion, suspend/resume approach have > several > > > > >> advantages > > > > >> > > > >> over > > > > >> > > > >> > > > approach > > > > >> > > > >> > > > > > > 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 > > > > >> > > > >> > > > (for > > > > >> > > > >> > > > > > > > optimistic transactions only) > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > [1] > > > > >> https://issues.apache.org/jira/browse/IGNITE-11685 > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > пт, 3 мая 2019 г. в 08:10, Павлухин Иван < > > > > >> > > > >> vololo...@gmail.com>: > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > > 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 > > > > >> > > > >> > > > from > > > > >> > > > >> > > > > > > > > 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. > > > > >> > > > >> > > > As I > > > > >> > > > >> > > > > > > > > understood we are going to resume a tx > > before > > > > >> each > > > > >> > > cache > > > > >> > > > >> > > > operation 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 > > > > >> > > > >> > > > txs). > > > > >> > > > >> > > > > > > > > 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 > > > > >> > > > >> > > > proposed > > > > >> > > > >> > > > > > in > > > > >> > > > >> > > > > > > > > IEP is good or bad. I can only say that > it > > > > >> ressembles > > > > >> > > > >> current > > > > >> > > > >> > > > thick > > > > >> > > > >> > > > > > > > > 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 > > > > >> > > > >> > > > have > > > > >> > > > >> > > > > > a > > > > >> > > > >> > > > > > > > > bunch of client implementations for > > different > > > > >> > > languages. I > > > > >> > > > >> > > > suppose > > > > >> > > > >> > > > > > > > > that we can return to it a little bit > > later. > > > And > > > > >> I > > > > >> > > hope > > > > >> > > > >> that we > > > > >> > > > >> > > > will > > > > >> > > > >> > > > > > > > > do it. > > > > >> > > > >> > > > > > > > > > > > > >> > > > >> > > > > > > > > [1] > > > > >> > > > >> > > > > > > > > > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > > >> > > > >> > > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > >> > > > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support > > > > >> > > > >> > > > > > > > > > > > > >> > > > >> > > > > > > > > вт, 30 апр. 2019 г. в 13:24, Alex > Plehanov > > < > > > > >> > > > >> > > > plehanov.a...@gmail.com > > > > >> > > > >> > > > > > >: > > > > >> > > > >> > > > > > > > > > > > > > >> > > > >> > > > > > > > > > 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' > > > > >> > > > >> > > > status. > > > > >> > > > >> > > > > > > Can > > > > >> > > > >> > > > > > > > > any > > > > >> > > > >> > > > > > > > > > transactions expert help with review of > > > > >> IGNITE-5714? > > > > >> > > > >> > > > > > > > > > > > > > >> > > > >> > > > > > > > > > [1]: > > > > >> > > > >> > > > > > > > > > > > > > >> > > > >> > > > > > > > > > > > > >> > > > >> > > > > > > > > > > > >> > > > >> > > > > > > > > > > >> > > > >> > > > > > > > > > >> > > > >> > > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > >> > > > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support > > > > >> > > > >> > > > > > > > > > [2]: > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-5714 > > > > >> > > > >> > > > > > > > > > > > > > >> > > > >> > > > > > > > > > чт, 4 апр. 2019 г. в 11:32, Alex > > Plehanov < > > > > >> > > > >> > > > plehanov.a...@gmail.com > > > > >> > > > >> > > > > > >: > > > > >> > > > >> > > > > > > > > > > > > > >> > > > >> > > > > > > > > > > Vladimir, > > > > >> > > > >> > > > > > > > > > > > > > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the > near > > > > >> future. > > > > >> > > > >> > > > > > > > > > > > > > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir > > > Ozerov < > > > > >> > > > >> > > > > > voze...@gridgain.com > > > > >> > > > >> > > > > > > >: > > > > >> > > > >> > > > > > > > > > > > > > > >> > > > >> > > > > > > > > > >> Hi Alex, > > > > >> > > > >> > > > > > > > > > >> > > > > >> > > > >> > > > > > > > > > >> I think we should be able to handle > > many > > > > >> > > transactions > > > > >> > > > >> > > > through 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 > > > > >> > > > >> > > > them > > > > >> > > > >> > > > > > are > > > > >> > > > >> > > > > > > > > > >> coordinated through a single > > connection. > > > > >> The same > > > > >> > > > >> should > > > > >> > > > >> > > be > > > > >> > > > >> > > > > > > > > applicable to > > > > >> > > > >> > > > > > > > > > >> thin clients. Protocol is already > > > designed > > > > >> to > > > > >> > > handle > > > > >> > > > >> this, > > > > >> > > > >> > > > as we > > > > >> > > > >> > > > > > > > pass > > > > >> > > > >> > > > > > > > > > >> unique operation ID in order to > > > distinguish > > > > >> one > > > > >> > > > >> operation > > > > >> > > > >> > > > from > > > > >> > > > >> > > > > > > > > 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 > > > > >> > > > >> > > > bound > > > > >> > > > >> > > > > > to > > > > >> > > > >> > > > > > > > > threads > > > > >> > > > >> > > > > > > > > > >> artificially, I would say that the > > first > > > > >> step in > > > > >> > > > >> > > > implementation > > > > >> > > > >> > > > > > of > > > > >> > > > >> > > > > > > > > > >> transactions on thin clients should > be > > > > >> decoupling > > > > >> > > > >> > > > server-side > > > > >> > > > >> > > > > > > > > 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.a...@gmail.com> > > > > >> > > > >> > > > > > > > > > >> wrote: > > > > >> > > > >> > > > > > > > > > >> > > > > >> > > > >> > > > > > > > > > >> > Guys, so, do we need multiple > > > concurrent > > > > >> > > > >> transactions > > > > >> > > > >> > > per > > > > >> > > > >> > > > > > > > > connection? > > > > >> > > > >> > > > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > There are pros and cons for each > > > approach. > > > > >> > > > >> Difference > > > > >> > > > >> > > > between > > > > >> > > > >> > > > > > > > > > >> 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 > > > > >> > > > >> > > > transaction > > > > >> > > > >> > > > > > > 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 > > > > >> > > > >> > > > needed > > > > >> > > > >> > > > > > > > > > >> > - Implementation on the server > side > > > is > > > > >> more > > > > >> > > > >> complex > > > > >> > > > >> > > > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > What do you think? > > > > >> > > > >> > > > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > вт, 2 апр. 2019 г. в 16:29, Alex > > > Plehanov > > > > >> < > > > > >> > > > >> > > > > > > > plehanov.a...@gmail.com > > > > >> > > > >> > > > > > > > > >: > > > > >> > > > >> > > > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > > Ilya, > > > > >> > > > >> > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > > > We should be able to multiplex > > > several > > > > >> > > > >> transactions > > > > >> > > > >> > > > using > > > > >> > > > >> > > > > > 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 > > > > >> > > > >> > > > thin > > > > >> > > > >> > > > > > > client > > > > >> > > > >> > > > > > > > > to > > > > >> > > > >> > > > > > > > > > >> > > simplify move from one to > another. > > > It's > > > > >> the > > > > >> > > only > > > > >> > > > >> > > reason. > > > > >> > > > >> > > > > > But I > > > > >> > > > >> > > > > > > > > agree > > > > >> > > > >> > > > > > > > > > >> with > > > > >> > > > >> > > > > > > > > > >> > > you, the parameter is not very > > > useful. > > > > >> > > > >> > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > > вт, 2 апр. 2019 г. в 14:48, Ilya > > > > >> Kasnacheev < > > > > >> > > > >> > > > > > > > > > >> ilya.kasnach...@gmail.com>: > > > > >> > > > >> > > > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > >> Hello! > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >> > > > >> > > > > > > > > > >> > >> Pavel, I agree with you > > thorougly. > > > We > > > > >> > > should be > > > > >> > > > >> able > > > > >> > > > >> > > to > > > > >> > > > >> > > > > > > > multiplex > > > > >> > > > >> > > > > > > > > > >> > several > > > > >> > > > >> > > > > > > > > > >> > >> transactions using a single > > Client > > > > >> > > connection. > > > > >> > > > >> This > > > > >> > > > >> > > > means > > > > >> > > > >> > > > > > > > adding > > > > >> > > > >> > > > > > > > > > >> > >> Transaction id parameter to > every > > > > >> affected > > > > >> > > cache > > > > >> > > > >> > > > operation > > > > >> > > > >> > > > > > / > > > > >> > > > >> > > > > > > > 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 > > > > >> > > > >> > > > pooling > > > > >> > > > >> > > > > > > > (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 > > > > >> > > > >> > > > client > > > > >> > > > >> > > > > > > > > protocol it > > > > >> > > > >> > > > > > > > > > >> > would > > > > >> > > > >> > > > > > > > > > >> > >> be nice clean-up. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >> > > > >> > > > > > > > > > >> > >> Regards, > > > > >> > > > >> > > > > > > > > > >> > >> -- > > > > >> > > > >> > > > > > > > > > >> > >> Ilya Kasnacheev > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >> > > > >> > > > > > > > > > >> > >> вт, 2 апр. 2019 г. в 09:55, > Pavel > > > > >> Tupitsyn < > > > > >> > > > >> > > > > > > > ptupit...@apache.org > > > > >> > > > >> > > > > > > > > >: > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >> > > > >> > > > > > > > > > >> > >> > Alex, > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >> > > > >> > > > > > > > > > >> > >> > > now we can only support one > > > active > > > > >> > > > >> transaction > > > > >> > > > >> > > per > > > > >> > > > >> > > > > > > > connection > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >> > > > >> > > > > > > > > > >> > >> > I totally understand > > server-side > > > and > > > > >> > > protocol > > > > >> > > > >> > > > limitations > > > > >> > > > >> > > > > > > > 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.a...@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%3A+transactions+support > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >> > > > >> > > > > > > > > > >> > >> > > чт, 28 мар. 2019 г. в > 14:33, > > > > >> Dmitriy > > > > >> > > Pavlov > > > > >> > > > >> < > > > > >> > > > >> > > > > > > > > dpav...@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 > > > > >> > > > >> > > > ask > > > > >> > > > >> > > > > > > infra > > > > >> > > > >> > > > > > > > > if > > > > >> > > > >> > > > > > > > > > >> extra > > > > >> > > > >> > > > > > > > > > >> > >> > > > permissions to edit pages > > > should > > > > >> be > > > > >> > > added > > > > >> > > > >> for > > > > >> > > > >> > > > > > > committers. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > Sincerely, > > > > >> > > > >> > > > > > > > > > >> > >> > > > Dmitriy Pavlov > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > ср, 27 мар. 2019 г. в > > 13:37, > > > Alex > > > > >> > > > >> Plehanov < > > > > >> > > > >> > > > > > > > > > >> > plehanov.a...@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 > > > > >> > > > >> > > > 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 > > > > >> > > > >> > > > > > > > > > >> > >> connection > > > > >> > > > >> > > > > > > > > > >> > >> > 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 > > > > >> > > > >> > > > > > > > > > >> > >> 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? > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > ср, 27 мар. 2019 г. в > > > 11:59, > > > > >> > > Vladimir > > > > >> > > > >> Ozerov > > > > >> > > > >> > > < > > > > >> > > > >> > > > > > > > > > >> > >> voze...@gridgain.com>: > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > Hi Alex, > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > My comments was only > > > about > > > > >> the > > > > >> > > > >> protocol. > > > > >> > > > >> > > > Getting > > > > >> > > > >> > > > > > > > > current > > > > >> > > > >> > > > > > > > > > >> info > > > > >> > > > >> > > > > > > > > > >> > >> about > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 > > > > >> > > > >> > > > > > > > > > >> > >> need > > > > >> > > > >> > > > > > > > > > >> > >> > > 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.a...@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 = > 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 > > > > >> > > > >> > > > > > > > > > >> > >> 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? > > > > >> > > > >> > > > Should > > > > >> > > > >> > > > > > 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 > > > > >> > > > >> > > > should > > > > >> > > > >> > > > > > > not > > > > >> > > > >> > > > > > > > > worry > > > > >> > > > >> > > > > > > > > > >> > about > > > > >> > > > >> > > > > > > > > > >> > >> > any > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > uncompleted > > transaction > > > > >> started > > > > >> > > by > > > > >> > > > >> the > > > > >> > > > >> > > > previous > > > > >> > > > >> > > > > > > > user > > > > >> > > > >> > > > > > > > > of > > > > >> > > > >> > > > > > > > > > >> this > > > > >> > > > >> > > > > > > > > > >> > >> > > > > connection. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > ср, 27 мар. 2019 > г. в > > > > >> 11:02, > > > > >> > > > >> Vladimir > > > > >> > > > >> > > > Ozerov < > > > > >> > > > >> > > > > > > > > > >> > >> > voze...@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 > > > > >> > > > >> > > > > > > > < > > > > >> > > > >> > > > > > > > > > >> > >> > > > > voze...@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 > > > > >> > > > >> > > > > > > > > > >> > >> info > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > END - provides > > > commit > > > > >> flag, > > > > >> > > > >> returns > > > > >> > > > >> > > > void > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > Vladimir. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > On Wed, Mar 27, > > > 2019 at > > > > >> > > 8:26 AM > > > > >> > > > >> Alex > > > > >> > > > >> > > > > > > Plehanov < > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > plehanov.a...@gmail.com > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > wrote: > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> Sergey, yes, > the > > > > >> close is > > > > >> > > > >> something > > > > >> > > > >> > > > like > > > > >> > > > >> > > > > > > > silent > > > > >> > > > >> > > > > > > > > > >> > rollback. > > > > >> > > > >> > > > > > > > > > >> > >> > But > > > > >> > > > >> > > > > > > > > > >> > >> > > we > > > > >> > > > >> > > > > > > > > > >> > >> > > > > can > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> also implement > > > this > > > > >> on the > > > > >> > > > >> client > > > > >> > > > >> > > > side, > > > > >> > > > >> > > > > > just > > > > >> > > > >> > > > > > > > > using > > > > >> > > > >> > > > > > > > > > >> > >> rollback > > > > >> > > > >> > > > > > > > > > >> > >> > > and > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > ignoring > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> errors in the > > > > >> response. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> ср, 27 мар. > 2019 > > > г. в > > > > >> > > 00:04, > > > > >> > > > >> Sergey > > > > >> > > > >> > > > > > Kozlov < > > > > >> > > > >> > > > > > > > > > >> > >> > > > skoz...@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 > > > > >> > > > >> > > > do on > > > > >> > > > >> > > > > > > > > client > > > > >> > > > >> > > > > > > > > > >> > started > > > > >> > > > >> > > > > > > > > > >> > >> > TX? > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > On Tue, Mar > > 26, > > > > >> 2019 at > > > > >> > > > >> 10:41 PM > > > > >> > > > >> > > > Alex > > > > >> > > > >> > > > > > > > > Plehanov < > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > > > plehanov.a...@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-resource > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > semantics > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > in > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> the > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > thin > client > > > and > > > > >> > > > >> OP_TX_CLOSE will > > > > >> > > > >> > > > be > > > > >> > > > >> > > > > > > useful > > > > >> > > > >> > > > > > > > > here. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > Nikolay, > > > > >> suspend/resume > > > > >> > > > >> didn't > > > > >> > > > >> > > > work > > > > >> > > > >> > > > > > yet > > > > >> > > > >> > > > > > > > for > > > > >> > > > >> > > > > > > > > > >> > >> pessimistic > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > transactions. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > Also, > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > the main > > goal > > > of > > > > >> > > > >> suspend/resume > > > > >> > > > >> > > > > > > operations > > > > >> > > > >> > > > > > > > > is to > > > > >> > > > >> > > > > > > > > > >> > >> support > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > 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. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > вт, 26 > мар. > > > 2019 > > > > >> г. в > > > > >> > > > >> 22:17, > > > > >> > > > >> > > > Nikolay > > > > >> > > > >> > > > > > > > > Izhikov < > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > nizhi...@apache.org > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >: > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, > > Alex. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also > > have > > > > >> suspend > > > > >> > > and > > > > >> > > > >> > > resume > > > > >> > > > >> > > > > > > > > operations. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think > we > > > > >> should > > > > >> > > > >> support them > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 > > марта > > > > >> 2019 г., > > > > >> > > > >> 22:07 > > > > >> > > > >> > > > Sergey > > > > >> > > > >> > > > > > > > Kozlov > > > > >> > > > >> > > > > > > > > < > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > skoz...@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 > > > > >> > > > >> > > > > > > > > > >> > >> back > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > On > Tue, > > > Mar > > > > >> 26, > > > > >> > > 2019 > > > > >> > > > >> at 6:07 > > > > >> > > > >> > > > PM > > > > >> > > > >> > > > > > Alex > > > > >> > > > >> > > > > > > > > > >> Plehanov < > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > >> plehanov.a...@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 > > > > >> > > > >> > > > > > > > > > >> > >> have > > > > >> > > > >> > > > > > > > > > >> > >> > > > 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, > > > > >> > > > >> > > > > > > > > > >> > >> int > > > > >> > > > >> > > > > > > > > > >> > >> > > > > txSize); > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > > > public > > > > >> > > > >> > > ClientTransaction > > > > >> > > > >> > > > > > tx(); > > > > >> > > > >> > > > > > > > // > > > > >> > > > >> > > > > > > > > Get > > > > >> > > > >> > > > > > > > > > >> > >> current > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 > > > > >> > > > >> > > > > > > > > > >> > >> different > > > > >> > > > >> > > > > > > > > > >> > >> > > set > > > > >> > > > >> > > > > > > > > > >> > >> > > > > of > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > arguments. > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Some > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > of > the > > > > >> arguments > > > > >> > > may > > > > >> > > > >> be > > > > >> > > > >> > > > missing. > > > > >> > > > >> > > > > > > To > > > > >> > > > >> > > > > > > > > pass > > > > >> > > > >> > > > > > > > > > >> > >> arguments > > > > >> > > > >> > > > > > > > > > >> > >> > > > with > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> OP_TX_START > > > > >> > > > >> > > > > > > > > > >> > >> & > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > -- > > > > >> > > Best regards, > > > > >> > > Ivan Pavlukhin > > > > >> > > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Best regards, > > > > >> Ivan Pavlukhin > > > > >> > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > > >
