[
https://issues.jboss.org/browse/ISPN-6573?page=com.atlassian.jira.plugin....
]
Radim Vansa edited comment on ISPN-6573 at 5/3/16 5:16 AM:
-----------------------------------------------------------
So the functional API was not implemented yet for transactional mode; some graceful
failure to tell that user would be nice.
I did some work on this in
https://github.com/rvansa/infinispan/tree/ISPN-6573 but
I've realized that it needs even more effort, especially in TxDistributionInterceptor,
where the read* commands have to replicate to remote nodes. That means new command like
ClusteredGet(All)Command.
It's even more troublesome for read-write commands: transactional commands are
expected to be sent and executed only as part of the PrepareCommand. However, these
functional commands need to go to the owners, execute there (to provide return values, but
not apply the new values), and then execute second time (this time under locks) during
2PC. Or, ideally, the result of first execution should be stored on the remote site.
All in all, days or weeks of work.
was (Author: rvansa):
So the functional API was not implemented yet for transactional mode; some graceful
failure to tell that user would be nice.
I did some work on this in
https://github.com/rvansa/infinispan/tree/ISPN-6573 but
I've realized that it needs even more effort, especially in TxDistributionInterceptor,
where the read commands have to replicate to remote nodes.
Functional API does not work [correctly] in transaction context
---------------------------------------------------------------
Key: ISPN-6573
URL:
https://issues.jboss.org/browse/ISPN-6573
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.2.1.Final
Reporter: Krzysztof Sobolewski
Attachments: AbstractFunctionalCachestoreTest.java,
AbstractFunctionalInMemoryTest.java, FunctionalCachestoreTestNonTx.java,
FunctionalCachestoreTestTx.java, FunctionalInMemoryTestNonTx.java,
FunctionalInMemoryTestTx.java
What is needed: a functional write operation on a key on a node that is not the key's
owner, with cache loader enabled. What happens then is in non-transactional context it
works fine; It starts failing when the functional operation is done in a transaction.
Looks like the entry is wrapped prematurely, which puts it into the context's looked
up nodes with the null value; the cache loader skips because the key is not local; and
when it reaches Command.perform(), it still has null value. In the non-tx context this
works OK because the command returns early if the entry is null (not wrapped) and then it
is properly sent across the cluster. But in tx context it gets confused and invokes the
functional operation on the local node even if it's not the owner. The functional
operation gets an empty entry even though the cache loader would load it. It then modifies
the entry, but the modification is not propagated anywhere because the tx distribution
interceptor... well, because it doesn't handle this command at all? And the change is
(apparently) not committed on the local node because it's not an owner.
Oh, and if the node *is* an owner it doesn't help :)
The tests are also available at
https://gist.github.com/ksobolew/74bb8ff6b321786e64a62ecd0e4c5878/836905d...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)