Re: C++ thin/thick client: how do a do SQL queries on a distant server?
Hi j.david, It seems that here is answer http://apache-ignite-users.70518.x6.nabble.com/SQL-API-in-C-thin-client-td28128.html Also, generally u...@ignite.apache.org mail list is suitable for such questions. On dev list discussions related to contribution usually take place. вт, 28 мая 2019 г. в 01:06, j.da...@qwant.com : > > Everything is in the title. > > I'd like to either manipulate SQL queries or serialized Object on a distant > ignite cluster, > but so far, I only found how to define endPoints on the thin client > configuration (nothing equivalent > on the thick client). > I haven't found how to do anything else than key/scalar-value using the thin > client. > > Thx in advance > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ -- Best regards, Ivan Pavlukhin
C++ thin/thick client: how do a do SQL queries on a distant server?
Everything is in the title. I'd like to either manipulate SQL queries or serialized Object on a distant ignite cluster, but so far, I only found how to define endPoints on the thin client configuration (nothing equivalent on the thick client). I haven't found how to do anything else than key/scalar-value using the thin client. Thx in advance -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-11874) Fix mismatch between idle_verify results with and without -dump option.
Denis Chudov created IGNITE-11874: - Summary: Fix mismatch between idle_verify results with and without -dump option. Key: IGNITE-11874 URL: https://issues.apache.org/jira/browse/IGNITE-11874 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Assignee: Denis Chudov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Thin client: transactions support
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, Павлухин Иван : > 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 : > > > > 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, Павлухин Иван : > > > > > 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 : > > > > > > > > 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 "ClientTransactionConfiguration" inside > > > > > "ClientConfiguration". > > > > > > > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван : > > > > > > > > > >> 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 : > > > > >> > > > > > >> > > 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 = --
Re: Thin client: transactions support
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 : > > 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, Павлухин Иван : > > > 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 : > > > > > > 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 "ClientTransactionConfiguration" inside > > > > "ClientConfiguration". > > > > > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван : > > > > > > > >> 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 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 : > > > >> > > > > >> > > 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 = -- per SQL client session > > > >> > > > (usually physical network connection) > > > >> > > > set global tx_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 : > > > >> > > > > > > > >> > > > > 1. In my opinion, having client-specific transaction > > parameters is > > > >> > > > expected > > > >> > > > > for > > > >> > > > > client when have different arguments
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 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, Павлухин Иван : > 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 : > > > > 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 "ClientTransactionConfiguration" inside > > > "ClientConfiguration". > > > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван : > > > > > >> 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 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 : > > >> > > > >> > > 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 = -- per SQL client session > > >> > > > (usually physical network connection) > > >> > > > set global tx_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 : > > >> > > > > > > >> > > > > 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
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 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 : > > 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 "ClientTransactionConfiguration" inside > > "ClientConfiguration". > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван : > > > >> 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 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 : > >> > > >> > > 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 Павлухин Иван > >> 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 = -- per SQL client session > >> > > > (usually physical network connection) > >> > > > set global tx_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 : > >> > > > > > >> > > > > 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 > >> > >
