To: user@ignite.apache.org
Subject: Re: Ignite transactions
Hi, Andrey
tx.start() — thread1
cache1.put|get — thread1
cache2.put|get — thread1
tx.commit — thread1
log operation
i didn`t see the problem here
Thanks Pavel!
1. According to business logic, I must transactionally change
I can assume that I can use either queues or a separate thread for
>these purposes.
>
>Нестрогаев Андрей
>
>From: Pavel Tupitsyn < ptupit...@apache.org >
>Sent: Wednesday, February 14, 2024 12:13 PM
>To: user@ignite.apache.org
>Subject: Re: Ignite t
Does anyone have a solution / workaround? We haven’t been able to find an
alternative so far.
Jay
From: Нестрогаев Андрей Викторович
Sent: Wednesday, 14 February 2024 10:41
To: 'user@ignite.apache.org'
Subject: RE: Ignite transactions
1. Perhaps in earlier versions I cou
Subject: RE: Ignite transactions
Thanks Pavel!
1. According to business logic, I must transactionally change the values in
2 caches; in the course of my actions, I must log all these actions in the 3rd
cache (protocol of my actions). So, it doesn’t matter whether my changes in
these first two
@ignite.apache.org
Subject: Re: Ignite transactions
1. Not sure I understand
2. Messaging is not transactional
3. No
4. No, transactions are tied to a specific thread
On Wed, Feb 14, 2024 at 11:01 AM Нестрогаев Андрей Викторович
mailto:a.nestrog...@flexsoft.com>> wrote:
Hi All,
Maybe someo
1. Not sure I understand
2. Messaging is not transactional
3. No
4. No, transactions are tied to a specific thread
On Wed, Feb 14, 2024 at 11:01 AM Нестрогаев Андрей Викторович <
a.nestrog...@flexsoft.com> wrote:
> Hi All,
>
>
>
> Maybe someone has already researched these questions:
>
> 1. How
Hi All,
Maybe someone has already researched these questions:
1. How can you organize nested/autonomous transactions in ignite? For example,
for the purpose of writing a protocol to another cache, so that the protocol is
saved regardless of the result of the main transaction.
2. If you use
Hello!
I doubt that there's much expertise here on the behavior of 2.4.0.
Regards,
--
Ilya Kasnacheev
чт, 2 апр. 2020 г. в 20:34, rc :
> Hello experts,
>
> Cluster details: Running Ignite 2.4.0 with 3 servers and 4 clients.
>
> Observed transaction timeouts after a server node restarted.
Hello experts,
Cluster details: Running Ignite 2.4.0 with 3 servers and 4 clients.
Observed transaction timeouts after a server node restarted. Upon further
investigation, it was due to PME failures and also saw that there were some
long running transactions on a cache for the same key for more
Thanks guys for response
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi Ashish,
Yes, a transaction will be rolled back if it closed without a successful
commit.
Thanks,
Mike.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Closing is enough and an explicit rollback is not necessary.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
For below code snippet, if exception occurs do I need to rollback the
transaction? Or closing the transaction takes care of it?
try (Transaction tx = transactions.txStart()) {
Integer hello = cache.get("Hello");
if (hello == 1)
cache.put("Hello", 11);
cache.put("World",
Hello!
I have noticed that you have READ_COMMITTED isolation when reading. It will
doubtlessly lead to situation when you read value from TXN-1 to set1 while
TXN is in progress, and then will read value from TXN to set2 because it is
committed already.
Don't you see it as a problem?
Regards,
--
Hi!
We try to isolate read transaction from write transaction. So, we write to
two transactional caches and commit transaction. From another thread we
read from both caches (READ_COMMITED). Ignite isolate data change for every
single cache, but not for both caches simultaneously.
In Oracle
Igniters,
Akmal Chaudhri has a new blog post headlined, "Apache Ignite Transactions
Architecture: Failover and Recovery
<https://www.gridgain.com/resources/blog/apache-ignite-transactions-architecture-failover-and-recovery>.”
Summary: Various types of cluster failures can occur
Igniters, as most of you are aware, Apache Ignite supports a range of different
Application Programming Interfaces (APIs). Akmal Chaudhri just published the
first in a multi-part series offering a detailed look at how Apache Ignite
manages transactions in its key-value API and some of the
Hi,
Please note that cache.get(N) does not lock all "rows" inside a transaction.
It just locks "row" with N key.
Actually, you should not lock data that is not involved in the transaction.
That is why the explicit lock is prohibited. It should be done out of
transaction scope.
If your case
Hi
I'm using Ignite Transactions(Ignite Version 2.1.0 and
*TransactionConcurrency.PESSIMISTIC,TransactionIsolation.REPEATABLE_READ*")
and after starting a transaction I need to lock certain rows.
According to Ignite 2.1.0 Documentation
*"Explicit locks are not transactional
for this
single operation. Non-transactional operations are always executed outside
of the transactional context, regardless of weather explicit transaction
exists in the current thread or not.
-Val
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transactions-and-non
s message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transactions-and-non-committed-entries-tp6451p6485.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
ue]
Jul 21, 2016 3:35:21 PM org.apache.ignite.logger.java.JavaLogger info
INFO: Topology snapshot [ver=11, servers=4, clients=1, CPUs=24, heap=7.6GB]
Jul 21, 2016 3:35:23 PM com.juan.ignite.ClientIgnite main
INFO: Size=0
Jul 21, 2016 3:35:25 PM com.juan.ignite.ClientIgnite main
INFO: Size=0
--
View this message
Hi Amit,
amitpa wrote
> Can Ignite transactions work if Grids are out process?
>
> Why is this document written in Ignite Spring Transaction Manager :-
> >Start an Ignite node with proper configuration in embedded mode?
>
> Can Ignite Transactions work only when Gri
ode that initiated
transaction during its commit, regardless of how entries involved in
transaction are distributed across nodes. So the answer is YES - you're not
going to have any consistency issues if you run the transaction properly.
-Val
--
View this message in context:
http://apache-ignite-u
entities Person and Account
> should be written sync to the Db through the same JVm and in the same case
> also the same happens.
>
> Can you guys please suggest an alternative or the way to configure this?
> Please note that my caches are now Atomic and Transactional and are
25 matches
Mail list logo
