[infinispan-dev] rethinking ISPN transactions

ben.cotton ben.cotton at jpmorgan.com
Fri Dec 6 10:11:06 EST 2013


Ø  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?





From: Mircea Markus-2 [via Infinispan Developer List] [mailto:ml-node+s980875n4028545h88 at n3.nabble.com]
Sent: Wednesday, December 04, 2013 6:47 AM
To: Cotton, Ben
Subject: Re: [infinispan-dev] rethinking ISPN transactions

On Dec 4, 2013, at 11:39 AM, Mark Little <[hidden email]</user/SendEmail.jtp?type=node&node=4028545&i=0>> 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]</user/SendEmail.jtp?type=node&node=4028545&i=1>
https://lists.jboss.org/mailman/listinfo/infinispan-dev

________________________________
If you reply to this email, your message will be added to the discussion below:
http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-rethinking-ISPN-transactions-tp4028325p4028545.html
To start a new topic under Infinispan Developer List, email ml-node+s980875n2085493h76 at n3.nabble.com
To unsubscribe from Infinispan Developer List, click here<http://infinispan-developer-list.980875.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2085493&code=YmVuLmNvdHRvbkBqcG1vcmdhbi5jb218MjA4NTQ5M3wyNjQyNTgwNjE=>.
NAML<http://infinispan-developer-list.980875.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.




--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-rethinking-ISPN-transactions-tp4028325p4028551.html
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131206/24550286/attachment-0001.html 


More information about the infinispan-dev mailing list