Alexey,
could you please describe Transaction interface?
Also it would be great to have a couple examples of using the proposed API.
On Tue, Jul 13, 2021 at 4:43 PM Alexei Scherbakov
wrote:
>
> Folks,
>
> I've prepared a PR implementing my vision of public transactions API.
>
> API is very
> avoid any thread based control of transactions...
> single thread will be able to work with any amount of
> transactions at the same time
Yes, and one TX can be used by many threads, which is demonstrated
by testTxAsync.
I completely agree with this approach.
Ok, let's see what others say
Pavel,
"runInTransaction" is supposed to provide an "old-fashioned" way to write a
transaction for easier migration.
Manual enlisting of tables is required, because I strive to avoid any
thread based control of transactions in Ignite 3.
Actually, a single thread will be able to work with any
Alexei,
The API looks good to me, except "runInTransaction", which I find confusing.
It looks like every operation performed by the passed Consumer will be
automatically enlisted in a transaction,
but, looking at tests, "withTx" call is still required inside the Consumer.
I don't think we need
Hi folks,
I've added proposed by Dmitriy baseBranchForTc as ignite 2.10, now
branches.json for ignite-2.11 looks like this
{
"id": "ignite-2.11-nightly",
"chains": [
{
"serverId": "apache",
"suiteId": "IgniteTests24Java8_RunAllNightly",
Folks,
I've prepared a PR implementing my vision of public transactions API.
API is very simple and similar to Ignite 2, but has some differences.
More details can be found here [1]
Share your thoughts.
[1] https://issues.apache.org/jira/browse/IGNITE-15086
--
Best regards,
Alexei
Hello, Slava.
This fix is required to fix the problem described in the ticket
description ("Cache group re-encryption does not start after cluster
secondary activation").
As for handling the exception in this case, from my point of view, the
impossibility of starting re-encryption is not critical
Hello Pavel,
Could you please assist me in understanding the fix that was implemented
under https://issues.apache.org/jira/browse/IGNITE-14424
In particular, it seems odd to me, just logging an exception in case
starting re-encryption failed with an error/exception.
Please take a look at
Pavel, actually, setters in builder is not ok. But as for me, the better
approach is something like this:
IgniteClient client = IgniteClient.start("127.0.0.1:10800")
or
CompletableFuture client =
IgniteClient.startAsync(IgniteClientConfiguration.builder()
.addresses("127.0.0.1:10800)
Val,
Ivan D has convinced me above to try the builder pattern, which is used by
many other drivers (Redis, Mongo, etc).
With IgniteClient class in ignite-client module:
Ignite client = IgniteClient.builder()
.setAddresses("127.0.0.1:10800")
.setTimeout(5000)
.build();
What do you
10 matches
Mail list logo
