On 1 Jun 2011, at 08:26, Jonathan Halliday wrote:
>
> some general comments:
>
> - preserving some subset of the existing transactional guarantees is all well
> and good BUT if the user is relying on additional 'guarantees' that are not
> preserved in all cases then they'll be in trouble. Therefore, it's essential
> to document not just what the minimum expected guarantees for a given config
> are, but also that no additional properties that may coincidently be observed
> are actually guaranteed. Some vendors go further and explicitly document the
> bad things that may happen with given settings, since in some cases these are
> not easy to reproduce in testing.
Agreed: https://issues.jboss.org/browse/ISPN-1146
>
> - aquiring locks in defined (e.g. HC) order is kind of obvious and I'm
> surprised it's not default behaviour.
It is the default behaviour indeed. We are considering an option to reorder
lock acquisition in order to avoid deadlocks[1]. Enablable through a
configuration.
> It probably should be as soon as the implementation is stable. Additionally,
> rather than making consecutive RPCs to a node for each of the keys it owns,
> why not locally walk the full set of objects in the tx first and batch them
> by owning node, then make one call to each node with the whole batch of lock
> requests?
The futures[2] API does something similar, but not quite that though.
Interesting optimisation for the Future API.
>
> - I'm rather suspicions of any discussion that includes phrases like 'it will
> have to rollback its running transactions'.
> A node in an XA transaction that has already prepared CAN'T rollback, the
> protocol does not allow it.
yes, totally agree. And since 5.0 we don't do that anymore.
> So, optimisations using non-replicated locks for replicated data should be
> disabled if the tx is under external control e.g. XA rather than local to
> infinispan. For that matter I think you'll have trouble with internal
> transactions too in some failure cases, but at least they won't affect me :-)
[1] http://community.jboss.org/wiki/PossibleLockingImprovements, see section #3.
[2] http://community.jboss.org/wiki/AsynchronousAPI
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
