-
1. Re: questions on 5.3 alpha (nuclear penguin)
pruivo Apr 17, 2013 5:50 PM (in response to cotton.ben)1 of 1 people found this helpfulBen Cotton wrote:
1. Re: the feature of supporting Total Order transactional protocol (via provider CloudTM). Where this is "transactional" ... I assume it is in the STM sense (where even operator isolation is supported) as opposed to in the ACID sense (where only operand isolation is supported). Can you confirm this? e.g. is ISOLATION=Linearizable actually a capabilty in nuclear-penguin? (P.S. one day I got to "pow-wow" with you guys re: how appropriate it is that a "nuclear" penguin support "atomic" capabilities. :-) )
Hi Ben,
I'm not sure if I understood your question. The transactional part here means that it is only available for transactional cache.
About the isolation levels, we are not adding or removing any isolation levels from the existing ones. In the particular case of linearizability, it is not supported because non-conflicting transaction are allowed to commit by any order (probably it does not happen a lot).
The main difference from the default behavior is that the default acquires locks to avoid conflicting transaction to be committed in different order in different nodes while, in total order, this order is provided by JGroups by ensuring the same deliver order in all the nodes.
If you have more questions about Total Order, let me know.
Cheers,
Pedro
-
2. Re: questions on 5.3 alpha (nuclear penguin)
cotton.ben Apr 17, 2013 7:12 PM (in response to pruivo)Thanks for the response Pedro.
FYI - what I was trying to discover was whether or not Total Order (which, as I understand it, is via CloudTM - a synchronized transactional memory (STM) provider) made available isolation levels beyond what is needed for ACID transactions (where the highest level needed is SERIALIZABLE).
For Isolation=SERIALIZABLE (in ACID) the operands (e.g. data entities) are protected (i.e. fully isolated) from conflict that could arrise from the interleave of concurrent operators (e.g. CRUD operations).
For Isolation=LINEARIZABLE (in STM) the operators (e.g. increment/decrement) are protected (i.e. fully isolated) from conflict that could arrise from the interleave of concurrent threads . e.g.
java.lang.Integer i;
i++; // not protected as Linearizable, app code must use synchronized keyword to achieve Linearizable
java.util.concurrent.AtomicInteger ai;
ai.incrementAndGet(); // protected as Linearizable, app code does not need to use synchronized keyword
You absolutely right ... specifying isolation=LINEARIZABLE is not needed too much. :-) But I am curious if it may indeed have some Caching/Grid use case. And if that Caching/Grid use case could find real accommodation via Infinispan's nucelar pigeon implementation.
Is it fair to say (and I admit that I haven't done my full homework) that Total Order via CloudTM provides for a "grid ACID transaction" the same capability that JBoss TM provides for "single-node ACID transaction"? Does it provide classic STM service in any way? Could you point me to some newbie literature re: how this is implemented and used via an API?
Thanks again,
Ben
-
3. Re: questions on 5.3 alpha (nuclear penguin)
cotton.ben Apr 17, 2013 7:31 PM (in response to cotton.ben)Ben Cotton wrote:
.... via Infinispan's nucelar pigeon implementation.
OMG. Forgive me ... I meant to say nuclear penguin implementation.
-
4. Re: questions on 5.3 alpha (nuclear penguin)
pruivo Apr 17, 2013 7:58 PM (in response to cotton.ben)Ben Cotton wrote:
FYI - what I was trying to discover was whether or not Total Order (which, as I understand it, is via CloudTM - a synchronized transactional memory (STM) provider) made available isolation levels beyond what is needed for ACID transactions (where the highest level needed is SERIALIZABLE).
just to be sure, Cloud-TM in this context refers to an European project (http://www.cloudtm.eu) right?
Ben Cotton wrote:
Is it fair to say (and I admit that I haven't done my full homework) that Total Order via CloudTM provides for a "grid ACID transaction" the same capability that JBoss TM provides for "single-node ACID transaction"? Does it provide classic STM service in any way? Could you point me to some newbie literature re: how this is implemented and used via an API?
The ACID properties are respect, but the isolation level ensured are non-serializable (i.e. read-committed and repeatable-read). I wrote a paper about total order implemented in Infinispan during my master thesis. You can find it here: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6133071&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6133071
The user documentation is not available yet. I'm still polishing it and benchmarking the code.
-
5. Re: questions on 5.3 alpha (nuclear penguin)
cotton.ben Apr 17, 2013 8:57 PM (in response to pruivo)Pedro Ruivo wrote:
just to be sure, Cloud-TM in this context refers to an European project (http://www.cloudtm.eu) right?
Correct. I got the reference from here = http://infinispan.blogspot.co.uk/2013/04/infinispan-530alpha1-is-out.html
Pedro Ruivo wrote:
The ACID properties are respect, but the isolation level ensured are non-serializable (i.e. read-committed and repeatable-read).
Without providing SERIALIZABLE, does that imply that Total Order cannot accommodate PHANTOM_READ intolerant use cases?
Pedro Ruivo wrote:
I wrote a paper about total order implemented in Infinispan during my master thesis. You can find it here: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6133071&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6133071 The user documentation is not available yet. I'm still polishing it and benchmarking the code.
Great work Pedro. Keenly awaiting the polished Total Order on Infinispan user documentation. :-)
-
6. Re: questions on 5.3 alpha (nuclear penguin)
pruivo Apr 18, 2013 5:33 AM (in response to cotton.ben)Now I understood where the SERIALIZABLE came from. In the project we develop higher isolation levels on top of Infinispan (GMU - update serializability and SCORe - one-copy serializability) and they are only available in the Cloud-TM prototype.
The current Infinispan (5.3 alpha1) has the Total Order based protocol but only for the current implemented isolation level, as I said. The phantom-read phenomenon can still happen with Total Order.
Cheers,
Pedro
-
7. Re: questions on 5.3 alpha (nuclear penguin)
nadirx Apr 18, 2013 5:54 AM (in response to cotton.ben)1 of 1 people found this helpfulAnswers to your other questions:
2. Re: JSR-107 support -- can you comment whether this is currently a nuclear-penguin ambition or truly in the penguin alpha build? if it is in the build, is it the 0.7 or 0.6 JCACHE API?
5.3.0.Alpha1 includes JCache 0.4 support, but current master is at 0.6. For your other questions in this scope I will leave it to Galder to answer, since he's the one doing most of the work in this sense.
5. does nuclear-penguin's JTA javax.transaction.UserTransaction provider have a tight-coupling to provider=JBoss TM? or could I (not that I would want to) configure the nuclear-penguin with a UserTransaction bridge to/from a different JTA provider?
No, you can use any JTA provider. See https://docs.jboss.org/author/display/ISPN/Infinispan+transactions
P.S. what is the relation ship between Red Hat product = "JBoss Data Grid 6.0.1" and the Infinispan tagged release numbers? This is the same code, correct? just branded w/ different product name?
JBoss Data Grid 6.0.1 is based on Infinispan 5.1.x. JBoss Data Grid 6.1.0 is based on Infinispan 5.2.x. The code is the same, however the productization process means that the code goes through extensive QA, stress, soak and resilience testing, security hardening and is supported for much longer.
Tristan
-
8. Re: questions on 5.3 alpha (nuclear penguin)
cotton.ben Apr 18, 2013 6:06 AM (in response to nadirx)Thanks Tristan!