On Nov 29, 2013, at 1:45 PM, Mark Little <mlittle(a)redhat.com> wrote:
I haven't looked at how ISPN does this today, but here are some
thoughts given how we do this within the transaction system for ACID transactions:
(i) have you considered async prepare?
There is a certain degree of asynchronicity in the sense that the prepare we send happens
in parallel on all the nodes involved in the transaction. Is this what you have in mind?
(ii) async commit/rollback could involve an external audit component to capture the
outcome of the transaction, which can be inspected later. Many years ago the OTS and CORBA
Notification Service did this together.
If the commit/rollback fails this should be picked up by the TM recovery process - I guess
that would do the job.
This improves the throughput indeed, but might be confusing for users: reading the data
written by a "successfully" completed transaction (i.e. TM.commit() returns
without exception) would not work.
(iii) if you don't allow heuristics then there are guarantees with async
commit/rollback.
Mark.
On 8 Nov 2013, at 15:28, Mircea Markus wrote:
> 1. Async options for commit/rollback
> - they don't really make sense as a user you don't get any guarantee on the
status of the transaction
> - they complicate the code significantly
> - I think they should be removed
---
Mark Little
mlittle(a)redhat.com
JBoss, by Red Hat
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).
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)