[jbosscache-issues] [JBoss JIRA] Created: (JBCACHE-1559) 0 ms MVCC timeout for invalidation commands
Brian Stansberry (JIRA)
jira-events at lists.jboss.org
Thu Dec 3 13:10:30 EST 2009
0 ms MVCC timeout for invalidation commands
-------------------------------------------
Key: JBCACHE-1559
URL: https://jira.jboss.org/jira/browse/JBCACHE-1559
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Locking
Affects Versions: 3.2.1.GA
Reporter: Brian Stansberry
Assignee: Manik Surtani
User reports getting timeout exceptions w/ 0 ms timeouts despite configuring JBC for longer timeouts. See forum thread for specific details. Key bit is here:
> The 0 ms is coming from MVCCLockInterceptor:
>
> Code:
>
> @Override
> public Object handleInvalidateCommand(InvocationContext ctx, InvalidateCommand command) throws Throwable
> {
> // this should be handled the same as a recursive evict command.
> ctx.getOptionOverrides().setLockAcquisitionTimeout(0);
> if (!command.getFqn().isRoot()) helper.wrapNodesRecursivelyForRemoval(ctx, command.getFqn());
> return invokeNextInterceptor(ctx, command);
> }
>
>
>
> I personally don't understand the reasoning behind that; the semantics of an invalidation are not the same as an evict, since an invalidation is concerned with data correctness while an evict is concerned with the > lesser issue of managing memory.
>
> Perhaps some of the folks who wrote this piece can comment?
>
> This exception is thrown when a lock is attempted on a remote node. One thing I can think of is that with INVALIDATION_SYNC there is no point waiting more than 0 ms to acquire the lock since whatever is holding > the lock on this node is before releasing it also going to send an invalidation message. Which won't succeed because whatever sent this message will be holding a lock. So might as well fail promptly.
>
> The above logic doesn't hold true with INVALIDATION_ASYNC though.
Galder and I just had a further discussion:
Brian: ok, so i think the logical flaw is just that 0 ms isn't correct for ASYNC
Galder: hmmm
Galder: why?
Galder: oh, because they could cross earch other?
Brian: well, first off, w/ ASYNC the TimeoutException won't propagate back to the sender, so only issue is what's the best state for the caches to end up in
Brian: so, yeah, they'll cross each other and both will invalidate
Brian: result is both caches are invalidated
Galder: but that's fine
Galder: they'll go back to db and get stuff from there
Brian: yep
Brian: w/ 0 ms timeout, whatever was holding the lock will succeed
Brian: because the invalidation msg from the other node will not succeed
Brian: so on one node you have potentially inconsistent data left in the cache
Galder: oh yeah, the remaining node has stale data
Galder: but u have the same problem with sync
Brian: w/ sync the TimeoutException propagates, allowing the caller to deal with it
Galder: yeah, the failure is at least known
Galder: the 2nd node could still succeed but you know the 1st did not
Galder: whereas with async, you don't know which one won
Brian: right
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbosscache-issues
mailing list