[
https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin....
]
William Burns updated ISPN-3273:
--------------------------------
Description:
When a write operation occurs causing a L1 invalidation, there is a boolean to say
assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the
originating node that caused this update. This works fine for the primary owner, however
any additional backups think the origin is the primary owner and such send invalidations
to possibly the real origin.
-This affects both tx and non tx caches. Tx caches that are sync don't see the
problem since locking prevents the invalidation, however it causes an unneeded network
roundtrip which can cause delay.-
Actually this only affects non-tx caches, as tx caches send the prepare/commit directly to
the owner(s) instead of having it relayed.
was:
When a write operation occurs causing a L1 invalidation, there is a boolean to say
assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the
originating node that caused this update. This works fine for the primary owner, however
any additional backups think the origin is the primary owner and such send invalidations
to possibly the real origin.
This affects both tx and non tx caches. Tx caches that are sync don't see the problem
since locking prevents the invalidation, however it causes an unneeded network roundtrip
which can cause delay.
Dist L1 owners that aren't primary don't respect
assumeOriginKeptEntryInL1
--------------------------------------------------------------------------
Key: ISPN-3273
URL:
https://issues.jboss.org/browse/ISPN-3273
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache
Reporter: William Burns
Assignee: William Burns
Attachments: DistSyncFuncTest.java
When a write operation occurs causing a L1 invalidation, there is a boolean to say
assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the
originating node that caused this update. This works fine for the primary owner, however
any additional backups think the origin is the primary owner and such send invalidations
to possibly the real origin.
-This affects both tx and non tx caches. Tx caches that are sync don't see the
problem since locking prevents the invalidation, however it causes an unneeded network
roundtrip which can cause delay.-
Actually this only affects non-tx caches, as tx caches send the prepare/commit directly
to the owner(s) instead of having it relayed.
--
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