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 >> >
