Andrey,
I suggest you look at the PR [1], if you haven't.
A transaction [2]
Transactions facade [3]
Examples [4]
[1] https://github.com/apache/ignite-3/pull/214/files
[2]
https://github.com/apache/ignite-3/blob/d2122ce8c15de020e121f53509bd5a097aac9cf2/modules/api/src/main/java/org/apache/ignite/
Alexey, and is there any analogue to close() of transaction? When you start
transaction, you should somehow to close it, if you don't catch exception
or forget to commit.
I suggest to add method closeAsync() to Transaction, so user can call it in
handle or whenComplete, i.e.
So code will looks li
Ivan,
We don't need the "close" method in the proposed approach, because it's
enough having "commit(Async)" and "rollback(Async)" to finish a
transaction. Semantically "close" is the same as "rollback".
If you are using "runInTransaction" API, you can't forget to call "close",
it will be done aut
>> Semantically "close" is the same as "rollback".
And what if I have already committed transaction? Is it safe rollback
already committed transaction? Rollback will silently return and do nothing?
ср, 14 июл. 2021 г. в 11:25, Alexei Scherbakov :
> Ivan,
>
> We don't need the "close" method in t
Agree with Ivan.
Method runInTransaction() should try to finish the transaction if the user
forgot to commit one.
I guess it might be a common mistake among new users.
Also, I suggest to extent all table projections for better UX.
Let's allow
table.kvView().withTx(tx)
to user may cache kvVew
Ivan,
And what if I have already committed transaction? Is it safe rollback
already committed transaction? Rollback will silently return and do
nothing? - yes, it is stated in the javadoc in the PR.
Andrey,
Then using "runInTransaction", lack of commit will cause a transaction to
rollback automa
Adding table.kvView().withTx(tx) seems fine to me.
ср, 14 июл. 2021 г. в 12:15, Alexei Scherbakov :
> Ivan,
>
> And what if I have already committed transaction? Is it safe rollback
> already committed transaction? Rollback will silently return and do
> nothing? - yes, it is stated in the javadoc
Alex,
I'm not sure CloseAsync() is useful.
As a user, I'd expect runInTransaction(closure) will create Tx for me,
commit Tx after a successful closure call, and rollback Tx in case of error.
However, I insist Transaction should extend AutoClosable, that may be
useful for synchronous case.
try
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to finalize
> yes, it is stated in the javadoc in the PR.
Ah, I see.
ср, 14 июл. 2021 г. в 12:16, Alexei Scherbakov :
> Ivan,
>
> And what if I have already committed transaction? Is it safe rollback
> already committed transaction? Rollback will silently return and do
> nothing? - yes, it is stated in the j
Andrey,
1) "As a user, I'd expect runInTransaction(closure) will create Tx for me,
commit Tx after a successful closure call, and rollback Tx in case of
error."
- I'm ok with this behavior, and will alter javadoc.
2) "Transaction tx = beginTx()" - there is no such method "beginTx" in the
proposed
> I don't think we need an explicit reactive API in the core library.
> Observable.fromFuture bridges async to Rx easily:
Cannot immediately agree here. Observable.fromFuture is not fair
reactive Publisher because computation for wrapped future most likely
starts before any subscription. While in
12 matches
Mail list logo
