[jira] [Created] (IGNITE-13556) .NET: Thin client: Transactions support async

Sergey Stronchinskiy created IGNITE-13556: - Summary: .NET: Thin client: Transactions support async Key: IGNITE-13556 URL: https://issues.apache.org/jira/browse/IGNITE-13556 Project: Ignite

Cpp thin client transactions support ready for review.

Thanks for all who participated in review. Cpp transactions functionality already in master. Appropriate wiki page [1] was updated.   [1] https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features   > > >Great, I'll take a look. > >Best Regards, >Igor > > >On Mon, Aug 24, 2020 at

Re: Cpp thin client transactions support ready for review.

Great, I'll take a look. Best Regards, Igor On Mon, Aug 24, 2020 at 8:33 AM Zhenya Stanilovsky wrote: > > > Thanks Ivan Daschinsky for review, does anyone more who could check it ? > > thanks ! > >Igniters, seems i complete with transactions in thin cpp client > >implementation [1], part of

Cpp thin client transactions support ready for review.

Thanks Ivan Daschinsky for review, does anyone more who could check it ?    thanks ! >Igniters, seems i complete with transactions in thin cpp client >implementation [1], part of iep-34 [2]. >Can anyone review my decision ? >Failed test seems not mine, looks like after fresh master rebase it

Cpp thin client transactions support ready for review.

  Igniters, seems i complete with transactions in thin cpp client implementation [1], part of iep-34 [2]. Can anyone review my decision ? Failed test seems not mine, looks like after fresh master rebase it will gone.   [1]  https://issues.apache.org/jira/browse/IGNITE-13308 [2] 

Re: Thin client: transactions support

Alex, thank you, I'm convinced now, no objections to ThinClientConfiguration. On Wed, Aug 28, 2019 at 12:59 PM Alex Plehanov wrote: > Pavel, we already have OdbcEnabled, JdbcEnabled and ThinClientEnabled > properties inside ClientConnectorConfiguration. ThinClientEnabled=false > does not assume

Re: Thin client: transactions support

Pavel, we already have OdbcEnabled, JdbcEnabled and ThinClientEnabled properties inside ClientConnectorConfiguration. ThinClientEnabled=false does not assume that JDBC thin client is disabled, it's clear and not confusing. I'm not agreed that the same situation with ThinClientConfiguration will be

Re: Thin client: transactions support

ThinClientConfiguration name is very confusing in existing situation. E.g. does it apply to JDBC Thin Client? No, it does not, but it is easy to assume it does. On Tue, Aug 27, 2019 at 5:07 PM Alex Plehanov wrote: > Ilya, Igor, > > Nested property is what exactly I've done in the last fix. >

Re: Thin client: transactions support

Ilya, Igor, Nested property is what exactly I've done in the last fix. ClientConnectorConfiguration now includes ThinClientConfiguration which contain only one property MaxActiveTxPerConnection for now. Pavel, Why do you think that nested ThinClientConfiguration is more confusing than property

Re: Thin client: transactions support

Hello! I think the nested property approach is correct. Sorry for causing the confusion. Regards, -- Ilya Kasnacheev вт, 27 авг. 2019 г. в 15:06, Igor Sapego : > Ilya, > > Sorry, I've just got your first message wrong. I though, you were > proposing to remove ClientConnectorConfiguration

Re: Thin client: transactions support

Ilya, Sorry, I've just got your first message wrong. I though, you were proposing to remove ClientConnectorConfiguration altogether, my bad. Now, about separating ClientConnectorConfiguration and - I do not propose to make it a copy with the same options. What I was proposing is to keep common

Re: Thin client: transactions support

Hello! I don't see why it should break backward compatibility and protocol. Can you please elaborate? I imagine that Thin client with TX muxing support will just send different requests to which server will respond differently. Why would anything break? Regards, -- Ilya Kasnacheev пн, 26 авг.

Re: Thin client: transactions support

Ilya, This will break backward compatibility and probably protocol, and this is not something we should discuss in the context of this specific task. More like this is a topic for 3.0 wishlist. Best Regards, Igor On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev wrote: > Hello! > > Also,

Re: Thin client: transactions support

Hello! Also, let's not add IGNITE_ settings for options that can reasonably be configured from IgniteConfiguration. Let's keep it for very edge cases. Regards, -- Ilya Kasnacheev пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev : > Hello! > > Do we still need to separate client connector

Re: Thin client: transactions support

Hello! Do we still need to separate client connector configuration from thin connector configuration from ODBC connector configuration? I think this is a bad practice: For example, people often turn on SSL or auth on just a subset of connectors, think they are secure, when in fact they still

Re: Thin client: transactions support

I think it is less confusing than ThinClientConfiguration. On Fri, Aug 23, 2019 at 8:49 PM Alex Plehanov wrote: > Pavel, > > ClientConnectorConfiguration is related to JDBC, ODBC and thin clients, the > new property only related to thin clients. If we put the new property > directly into

Re: Thin client: transactions support

Pavel, ClientConnectorConfiguration is related to JDBC, ODBC and thin clients, the new property only related to thin clients. If we put the new property directly into ClientConnectorConfiguration, someone might think that it also affects JDBC and ODBC. пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn

Re: Thin client: transactions support

t; > > > > > > Hi Alex, > > > > > > > > > > Could you please elaborate about thin client protocol versioning. > As > > I > > > > > see 1.5.0 is supposed to be a version supporting transactions. And > we > > > >

Re: Thin client: transactions support

e 1.5.0 is supposed to be a version supporting transactions. And we > > > > already have a version 1.4.0 with affinity awareness support. I > > > > forgot, does Java thin client support affinity awareness? Will it > work > > > > properly if it does not? &g

Re: Thin client: transactions support

> > > forgot, does Java thin client support affinity awareness? Will it work > > > properly if it does not? > > > > > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov : > > > > > > > > Hi Igniters, > > > > > > >

Re: Thin client: transactions support

ient support affinity awareness? Will it work > > properly if it does not? > > > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov : > > > > > > Hi Igniters, > > > > > > Finally, all dependent tickets are resolved and I've completed the > > > imple

Re: Thin client: transactions support

ot, does Java thin client support affinity awareness? Will it work > properly if it does not? > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov : > > > > Hi Igniters, > > > > Finally, all dependent tickets are resolved and I've completed the > > impleme

Re: Thin client: transactions support

if it does not? ср, 14 авг. 2019 г. в 13:59, Alex Plehanov : > > 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-s

Re: Thin client: transactions support

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

Re: Thin client: transactions support

eady have a good > approach for that. If not then I suppose it worth a discussion. > > пн, 27 мая 2019 г. в 12:51, Alex Plehanov : > > > > Hi Ivan. > > > > Thin client transactions support is not only for java thin client. There > > are other clients, some of them already work in as

Re: Thin client: transactions support

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 : > > Hi Ivan. > > Thin client transactions support is not only for java thin client. There > ar

Re: Thin client: transactions support

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 su

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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 : > Ivan, > > Yes, I have plans to do that (at least for java thin client). Something > like new class

Re: Thin client: transactions support

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, Павлухин Иван : > Alex, > > Are you going to introduce settings specifying default values for tx > concurrency

Re: Thin client: transactions support

Alex, Are you going to introduce settings specifying default values for tx concurrency and isolation in client configuration? пн, 20 мая 2019 г. в 19:34, Alex Plehanov : > > Igor, > > Perhaps we don't really need to use server's default values for tx > parameters. It's a minor fix and can be

Re: Thin client: transactions support

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 :

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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 = -- per SQL client session (usually physical network connection) set global

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

Vladimir, Ok, then I will rewrite IEP in the near future. чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov : > 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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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.

Re: Thin client: transactions support

Pavel, AFAIK usually, such limitations handled by using connection pools. If a thread needs to start a transaction, it acquires a connection from the pool and releases the connection after the transaction end. вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn : > Alex, > > > now we can only support

Re: Thin client: transactions support

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.

Re: Thin client: transactions support

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 : > Hi, > > I've added permissions to account plehanov.alex > >

Re: Thin client: transactions support

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 мар.

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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

Re: Thin client: transactions support

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 wrote: > Hi Alex, > > I am not sure we need 5 commands. Wouldn't it be enough to have only two? >

Re: Thin client: transactions support

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 wrote: > Sergey, yes, the close is something like

Re: Thin client: transactions support

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 : > Nikolay > > Am I correctly understand you points: > >- close: rollback >-

Re: Thin client: transactions support

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,

Re: Thin client: transactions support

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

Re: Thin client: transactions support

Hello, Alex. We also have suspend and resume operations. I think we should support them вт, 26 марта 2019 г., 22:07 Sergey Kozlov : > 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

Re: Thin client: transactions support

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 wrote: > Hello Igniters! > > I want to pick up

Re: Thin client: transactions support

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

Re: Thin client: transactions support

We already have transactions support in JDBC driver in TX SQL branch (ignite-4191). Currently it is implemented through separate thread, which is not that efficient. Ideally we need to finish decoupling transactions from threads. But alternatively we can change the logic on how we assign thread ID

Re: Thin client: transactions support

Here is an original discussion with a reference to the JIRA ticket: http://apache-ignite-developers.2346864.n4.nabble.com/Re-Transaction-operations-using-the-Ignite-Thin-Client-Protocol-td25914.html -- Denis On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy Setrakyan wrote: > Hi

Re: Thin client: transactions support

Hi Dmitriy. I don't think we have a design proposal for transaction support in thin clients. Do you mind taking this initiative and creating an IEP on Wiki? D. On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com> wrote: > Hi, Igniters. > > I've seen a lot of

Thin client: transactions support

Hi, Igniters. I've seen a lot of discussions about thin client and binary protocol, but I did not hear anything about transactions support. Do we have some draft for this purpose? As I understand we have several problems: - thread and transaction have hard related (we use thread-local