Rick, > What you are saying is that I cannot update keys 2 and 4 in the same transaction, correct? No, it's will be update in the same transaction. I explained you why Ignite can't update store from dht nodes (nodes which own this data) and why Ignite propagates updates to store from client node.
On Tue, Jun 6, 2017 at 5:42 PM, rick_tem <[email protected]> wrote: > Hi Nikolai, > > Thanks for your reply. It is appreciated! Thanks for your answer to 2) I > will look into it. 3) and 4) are really the same issue I am trying to > understand how it works. > > With regards to 1) below, we aren't speaking about distributed databases, > but distributed caches that are java JVMs. But isn't that what a JTA > transaction manager is supposed to do? ie handle distributed transactions? > if I enlist MQ and Jboss in the same transaction that is two seperate JVMs > and I believe should work with one atomic transaction... > > But regardless, I believe this is what you are saying here: Please correct > me if I am wrong. Say I have keys 1, 2, 3 on node 1 and keys 4, 5, 6 on > node 2. What you are saying is that I cannot update keys 2 and 4 in the > same transaction, correct? This is because they live in two different > JVMs...If this is the case, that is a severe limitation as then I need to > know which node my data is on. What would your recommendation be here then > for write-through cache? Have everything replicated? It is a requirement > that the transaction be rock solid in whatever model I implement. I cannot > afford to lose writes or have half-committed data. > > Thanks, > Rick > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/Why-is-custom-cacheStore-write-being- > called-in-clientMode-tp13309p13424.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
