You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by amitpa <am...@nrifintech.com> on 2016/05/03 07:35:37 UTC

Error on Transactions with Write Behind

I have one cache which is configured as write behind and another which has
read and write disabled.
When I try to create a transaction I get an error :- 

user-allow-subscribe@ignite.apache.org

 org.apache.ignite.IgniteCheckedException: Failed to enlist new cache to
existing transaction (caches with different write-behind setting can't be
enlisted in one transaction) 

Have you got any work arounds for this?





--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Error on Transactions with Write Behind

Posted by Denis Magda <dm...@gridgain.com>.
It depends on a contributor or committer who decides to implement the improvement.
Presently the ticket is unassigned so anyone can pick it up and work on it.

—
Denis

> On May 6, 2016, at 12:38 PM, amitpa <am...@nrifintech.com> wrote:
> 
> Hey, It does work with READ_COMMITTED
> 
> However, can you please let me know what is the expected release in which
> this fix will be included?
> 
> 
> 
> --
> View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736p4817.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.


Re: Error on Transactions with Write Behind

Posted by amitpa <am...@nrifintech.com>.
Hey, It does work with READ_COMMITTED

However, can you please let me know what is the expected release in which
this fix will be included?



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736p4817.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Error on Transactions with Write Behind

Posted by Alexey Goncharuk <al...@gmail.com>.
I think it makes sense not to validate store configuration unless we know
that the entry is enlisted as WRITE.

I've created the issue: https://issues.apache.org/jira/browse/IGNITE-3086

2016-05-04 5:28 GMT-07:00 Denis Magda <dm...@gridgain.com>:

> As Val already mentioned you can't mix write-through and write-behind
> caches
> in a single transactions.
>
> However, in my understanding I don't see any reason why we can't mix these
> caches taking into account that the one will be used for 'read' operations
> only.
>
> Alex G. or Sam can you share your thoughts? Do we need to create a JIRA
> ticket?
>
> In any case presently I see the following solutions:
>
> 1) make all caches that participate in the transaction either write-through
> or write-behind;
>
> 2) use IgniteCache.getAllOutTxAsync(...) for the cache that is used to read
> data, probably it will work in your case. Note that this should be used
> only
> if you don't want to acquire locks during the read operation from the
> cache.
>
> 3) use READ_COMMITTED isolation level instead of REPEATABLE_READ (default
> one). However, the lock won't be acquired on the 'get' operation as in case
> 2.
>
> --
> Denis
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736p4764.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Error on Transactions with Write Behind

Posted by Denis Magda <dm...@gridgain.com>.
As Val already mentioned you can't mix write-through and write-behind caches
in a single transactions.

However, in my understanding I don't see any reason why we can't mix these
caches taking into account that the one will be used for 'read' operations
only.

Alex G. or Sam can you share your thoughts? Do we need to create a JIRA
ticket?

In any case presently I see the following solutions:

1) make all caches that participate in the transaction either write-through
or write-behind;

2) use IgniteCache.getAllOutTxAsync(...) for the cache that is used to read
data, probably it will work in your case. Note that this should be used only
if you don't want to acquire locks during the read operation from the cache.

3) use READ_COMMITTED isolation level instead of REPEATABLE_READ (default
one). However, the lock won't be acquired on the 'get' operation as in case
2.

--
Denis



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736p4764.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Error on Transactions with Write Behind

Posted by amitpa <am...@nrifintech.com>.
One of my cache has actually read write through disabled.  Another has write
behind enabled. I am still getting the conflict. The first cache is used to
read some values, where as the other one is used for writing.

Should there be a conflict in this case? (The first cache only has some
reference data, where as the second one is used for writing to the database
asynchronously ).



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736p4749.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Error on Transactions with Write Behind

Posted by vkulichenko <va...@gmail.com>.
Hi,

The only workaround is to split this into two transactions (not sure if it's
acceptable for you). Different write-behind behavior in a single transaction
is not allowed, because they are processed differently. With write-through
cache store is updated from the client, so that you can maintain consistency
between cache and DB, which with write-behind store is update asynchronously
from different server nodes.

What's your use case? Can you provide more details on what you're trying to
achieve?

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Error-on-Transactions-with-Write-Behind-tp4736p4747.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.