[
https://issues.jboss.org/browse/ISPN-2300?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-2300:
-------------------------------------
{quote}In the current code base, when a versioned entry fails to update due to conditional
operation not fulfilling the condition, the previous value entry is added to the context
with isChanged=true (if present in the cache, as a result of marking
RepeatableReadEntry.copyForUpdate), and then EntryWrappingInterceptor loops through all
the entries in the context, and if "changed", it will try commit them.{quote}
A better fix would be for the previous value to have its isChanged flag set to false
rather than true. The flag being set to true is incorrect, as the entry is not actually
changed and might cause problems in other scenarios as well. The value of the flag can be
set in the conditional command perform() method.
Versioned Transactional Cache issues
------------------------------------
Key: ISPN-2300
URL:
https://issues.jboss.org/browse/ISPN-2300
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.2.0.Alpha3
Reporter: Pedro Ruivo
Assignee: Galder ZamarreƱo
Priority: Critical
Labels: Commands, Conditional, Transactions, Version
Fix For: 5.2.0.CR2, 5.2.0.Final
Description from
http://lists.jboss.org/pipermail/infinispan-dev/2012-September/011205.html
1) testPutIfAbsent, testRemoveIfPresent, testReplaceWithOldVal (methods
the test cases)
In this tests, it was updating the cache entry with a null version. This
originates later a IllegalStateException when it tries to perform the
write skew check and the version is null.
I have fixed this problem in this way: if the command fails (PutCommand,
RemoveCommand, ReplaceCommand), I unset the flag CHANGED in the
MvccEntry to avoid to update the entry in the DataContainer.
2) testClear in distributed mode
I have no clear idea how to solve this problem but it looks like the
PrepareCommand (with the ClearCommand) is not sent to all the nodes in
the cluster. Then, when I do a get, a remote get is performed and the
key is still there. I think that it is not the desired behavior.
3) testRemoveUnexistingEntry
In this test, it tries to remove a key that does not exists but it does
not success due to a NullPointerException. I have looked deeper and I
check that the transaction's lookup entries map has an entry with [key
=> null] and when it tries to perform the write skew check in that key,
a NullPointerException is thrown in here [2] (line 80, WriteSkewHelper)
[1]
https://github.com/pruivo/infinispan/tree/t_replace_fix
[2]
https://github.com/pruivo/infinispan/blob/t_replace_fix/core/src/main/jav...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira