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 >
