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
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
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.
> Cli
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 i
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 alto
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 se
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 авг.
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, let's
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 configur
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 have
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 Client
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
Igor, Alex,
Not sure I agree with this: ThinClientConfiguration inside
ClientConnectorConfiguration.
Very confusing IMO, because ClientConnectorConfiguration is already related
to thin clients only.
Why not put the new property directly into ClientConnectorConfiguration?
Igor,
Make sense. I've fixed the implementation according to your proposal.
ср, 21 авг. 2019 г. в 17:59, Igor Sapego :
> Probably, we need separate configuration for
> Thin Clients as a part of ClientConnectorConfiguration?
>
> Best Regards,
> Igor
>
>
> On Thu, Aug 15, 2019 at 12:36 PM Alex Ple
Probably, we need separate configuration for
Thin Clients as a part of ClientConnectorConfiguration?
Best Regards,
Igor
On Thu, Aug 15, 2019 at 12:36 PM Alex Plehanov
wrote:
> Hi Pavel,
>
> Thank you for the review!
>
> Igniters,
>
> Also, I want to bring here a discussion about configuring li
Hi Pavel,
Thank you for the review!
Igniters,
Also, I want to bring here a discussion about configuring limit for active
transactions per thin client connection.
I see two ways to configure such limit:
1. A new system property
2. A new ClientConnectorConfiguration class property.
In the curren
Hi Alex,
I've checked the patch, protocol changes look good to me. See reply in Jira.
But we certainly need more eyes on this.
On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov
wrote:
> Hi Ivan,
>
> Java thin client doesn't support affinity awareness yet (ticket [1] is in
> progress now), but chan
Hi Ivan,
Java thin client doesn't support affinity awareness yet (ticket [1] is in
progress now), but changes to correctly work with protocol version 1.4.0
was made, so java thin client will work properly with 1.4.0 and 1.5.0
protocol versions.
[1]: https://issues.apache.org/jira/browse/IGNITE-11
Hi Alex,
Could you please elaborate about thin client protocol versioning. As I
see 1.5.0 is supposed to be a version supporting transactions. And we
already have a version 1.4.0 with affinity awareness support. I
forgot, does Java thin client support affinity awareness? Will it work
properly if i
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
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
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
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" im
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 thre
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 "
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 a
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 easi
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
opi
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_isolati
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
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
implementation
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 i
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_INF
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
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 n
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 simplicity
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
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
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
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.
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 one
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.
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
>
> Recently
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
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
ac
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 suppo
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 a
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?
>
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 s
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
>- co
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,
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 clien
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 un
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 t
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 transac
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
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 Dmitriy. I don't think we
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 discuss
59 matches
Mail list logo
