-
Enhancement
-
Resolution: Obsolete
-
Major
-
None
-
8.2.1.Final
-
None
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/836905d2384a17989e41979232b0f962c88f06f4
- duplicates
-
ISPN-5806 Add transaction support for Functional API
-
- Closed
-
[ISPN-6573] Functional API should support transactional caches
rvansa1@redhat.com ksobolewski_jira I made it an enhancement.
Krzysztof Sobolewski (Inactive)
added a comment - Okay. Couldn't you downgrade it to wishlist, though?
Krzysztof Sobolewski (Inactive)
added a comment - Okay. Couldn't you downgrade it to wishlist, though? 
Radim Vansa (Inactive)
added a comment - I am closing this since it's not a bug (nor feature ), just non-implemented use case.
Radim Vansa (Inactive)
added a comment - I am closing this since it's not a bug (nor feature ), just non-implemented use case. Krzysztof Sobolewski (Inactive)
added a comment - I see. Well, fortunately I can switch to non-transactional mode, so that's fine. Actually, I should switch to non-transactional mode because I don't need them for anything, really, and it will be faster, too
Krzysztof Sobolewski (Inactive)
added a comment - I see. Well, fortunately I can switch to non-transactional mode, so that's fine. Actually, I should switch to non-transactional mode because I don't need them for anything, really, and it will be faster, too 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.
Radim Vansa (Inactive)
added a comment - - edited 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. Krzysztof Sobolewski (Inactive)
added a comment - Answering to https://developer.jboss.org/message/955416#955416 ("Is this an issue only when cache store is involved, or are the functional operations broken in transactional mode completely?"): yes, it's broken in transactional mode completely. I'm attaching tests that illustrate this. FunctionalInMemoryNonTx passes, while FunctionalInMemoryTx fails.
Krzysztof Sobolewski (Inactive)
added a comment - Answering to https://developer.jboss.org/message/955416#955416 ("Is this an issue only when cache store is involved, or are the functional operations broken in transactional mode completely?"): yes, it's broken in transactional mode completely. I'm attaching tests that illustrate this. FunctionalInMemoryNonTx passes, while FunctionalInMemoryTx fails. 
Infinispan issue tracking has been migrated to GitHub issues: https://github.com/infinispan/infinispan/issues
If you still want this issue to be worked on, create a new issue on GitHub and link this issue.