Ø  That's smart, thanks for clarifying this.

 

It is smart.  And for some necessary …  implementing READ_COMMITTED as “block til their done” pays homage to the in-flight transactions’ ambitions to update.  Implementing READ_COMMITTED as “just give readers the old data” pays ZERO homage to the in-flight transactions’ ambitions to update.

 

Even better would be exposing some kind of API that empowers the user to specify READ_COMMITTED with either policy.

 

i.e.    accommodate both potential user isolation choices via some kind of

 

.setTxIsolation(READ_COMMITTED,  READERS_GET_OLD_DATA);  //pessimistic wrt to in-flight tx?

.setTxIsolation READ_COMMITTED,  READERS_BLOCK_UNTIL_IN_FLIGHT_TXS_OUTCOME); //optimistic wrt to in-flight tx?

 

API capability

 

Does ISPN transactions offering have the ambition to provide both in the API?

 

 

 

 

 

 

On Dec 4, 2013, at 11:39 AM, Mark Little <[hidden email]> wrote:

> Yes, I understand that. My point is that in some environments where async commit is possible they also (opaquely) tie in the read requests to data such that they can block if the commit hasn't completed.

That's smart, thanks for clarifying this.

Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)





_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev