-
15. Re: New state transfer in JBoss Cache
"bela@jboss.com" wrote:
Waiting for a TX to complete brings us back to the initial solution (wait-then-break-the-locks), which we thought was not good as it would (1) need time to wait for completion and (2) cause TXs to get rolled back.
You mean, (1) wait for completion OR (2) cause TXs to get rolled back. Yes, this does become a problem but at least all it does is delay the instance joining the cluster and won't impact the existing instances."bela@jboss.com" wrote:
Regarding proxying: who redirects the caller from A to B ? What if A has state e.g. pertaining to a session that is available only on A and its buddy C (but not B) ?
I would assume the proxying is done by an interceptor on A, and this interceptor would need to know where to proxy to. -
16. Re: New state transfer in JBoss Cache
Ok, so after discussing this further with Bela and Jason earlier, I've updated the wiki. Could you guys please have a look and make sure we're all on the same page here.
Basically, the big changes are:- Idempotency is required, but we've determined that cache updates are idempotent provided updates are applied in order.
- No more proxying of local calls on the state provider.
- No more locking of local transactions from committing for the duration of state generation.