[infinispan-dev] weekly questions

[Jonathan Halliday]

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.

- aquiring locks in defined (e.g. HC) order is kind of obvious and I'm 
surprised it's not default behaviour. 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?

- 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. 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 :-)

Jonathan.

On 05/25/2011 12:55 PM, Mircea Markus wrote:
> Hi Jonathan,
>
> We're thinking about doing some significant changes/improvements around
> transactions[1]. I'd like to pick your brain especially on improvement
> #1, as this changes the way we acquire locks quite a bit.
>
> With this new locking approach, we don't acquire WL for a transaction
> until prepare phase. On each write we keep a copy of the written key on
> the node where transaction is executed so that each subsequent access,
> in the same transaction, would read/update this copy. Same goes for reads.
> When transaction commits we acquire WL during prepare time. This looks
> to me very similar to the optimistic CC, just that there's no conflict
> verification before commit.
> Also, it seems to preserve repeatable read transaction isolation correctly.
> This is a very significant change in our transaction model - do you see
> any problems/suggestions around it?
>
> Cheers,
> Mircea
>
> [1] http://community.jboss.org/wiki/PossibleLockingImprovements

-- 
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod 
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons 
(USA) and Brendan Lane (Ireland).