[infinispan-dev] weekly questions

[Mircea Markus]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110601/c07db425/attachment.html