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
