Please vote on some Transactions Options for JSR107

[Greg Luck]

Guys

Since Ludovic and I specified transactions behaviour, there has been much discussion about them. See https://github.com/jsr107/jsr107spec/issues/153 for a taste.

Since Yannis was involved these have been an Optional feature, as it was clear that not every implementation would want to implement them. On the flip side just about

everyone out there has transactions in some form with some isolation levels. e.g. BigMemory has Local and XA with READ_COMMITTED only, which is the reason why

we specified them in the first place.

It is also pretty clear from my experience that transactions are a very seldom used feature. The evidence for this has been mounting in the three years since we started work

on the spec. This is based on our own customer usage of BigMemory. So I see this part of the spec as less important than I used to.

While we have specified transactions in Chapter 5 of the spec, the RI does not implement them and there are no meaningful tests, other than a few simple API tests.

We think it likely that the EC will find this unacceptable and require us to implement and test. We did take advice from the PMO about this a few years ago, and there answer

was that we could do what we liked, but the EC particularly given this is important to EE will take a more restrictive view. This could be a very large amount of work. 

Also, as we have raised the quality of the spec, we have left transactions alone as it is sufficiently subtle that we wanted everything else nailed down very thoroughly first.

We need to clarify all sorts of transaction interactions around eviction, expiry, loaders, writers, listeners etc.

Finally as we have been running late, EE 7 has come and gone. Looking ahead to EE 8 and the many things that need to be thought through and specified for

107s inclusion in it, we think a separate JSR should be created for it.

With all of this mind, and as proposed by Ben Cotton I would like some guidance on what the EGs views are on our options:

Please put  +1 or -1 against each item as these are not all mutually exclusive.

1. Remove Transactions from the Spec  (Brian Oliver's suggestion)

2. Make XA and Local Transactions separate Optional Features (Bill Shannon's suggestion)

3. Make each of the isolation modes optional, so that an implementation can say which it has.

Regards

Greg Luck

web: http://gregluck.com

skype: gregrluck

yahoo: gregrluck

mobile: +61 408 061 622

[Jens Wilke]

Greg,

 

thanks for the poll.

 

On Thursday 29 August 2013 14:10:31 Greg Luck wrote:

> 1. Remove Transactions from the Spec  (Brian Oliver's suggestion)

 

+1

 

> 2. Make XA and Local Transactions separate Optional Features (Bill Shannon's

> suggestion)

> 3. Make each of the isolation modes optional, so that an

> implementation can say which it has.

 

These two are non-options, because the spec semantics are not clearly defined.

 

Suggestion:

 

4. Add Transactions as "non-normative" Section to the Standard and sum up what is learned so far.

 

Best,

 

Jens

 

--

"Everything superfluous is wrong!"

 

// Jens Wilke - headissue GmbH - Germany

\// http://www.headissue.com

[ben.c...@alumni.rutgers.edu]

>    1. Remove Transactions from the Spec  (Brian Oliver's suggestion)

-1

>    2. Make XA and Local Transactions separate Optional Features (Bill Shannon's suggestion)

+1

>    3. Make each of the isolation modes optional, so that an implementation can say which it has.

-1

[Steve Millidge]

Hi Greg,

 

What’s the time frame for the vote? I need to reread the section again and the arguments.

 

Steve Millidge
C2B2
The Leading Independent Middleware Experts. 
T: 08450 539457 |M: 07920 100626 |W: www.c2b2.co.uk | E: smil...@c2b2.co.uk
---------------------------------------------------------------------------------------------------------------
C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ
Registered in England and Wales: 4563419, Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire

[Yannis Cosmadopoulos]

1. Remove Transactions from the Spec  (Brian Oliver's suggestion)

  +1

2. Make XA and Local Transactions separate Optional Features (Bill Shannon'ssuggestion)

3. Make each of the isolation modes optional, so that an implementation can say which it has.

--
I will be participating (again) in the ALC bicycle ride, from San Francisco to Los Angeles, raising money to fight AIDS. Please support me: http://www.tofighthiv.org/goto/yannis

[Brian Oliver]

Thanks for the great write up Greg!  Very much appreciated.

For some additional clarity, I'm not advocating removing Transactions forever.   I'd simply like to see a greater invest so that;

a). Developers can reasonably expect to can create portable applications that use transactions (like the rest of the API) - this is not really possible at the moment.

b). Implementors have the ability to create implementations that pass a reasonable set of TCK tests, thus providing confidence for a).

Let's be very clear there.  Greg and Ludovic have done some seriously awesome and somewhat exhausting work to get to where we are.   However as Greg points out, we need to clarify a number of (non-trivial) semantic issues and interactions with parts of the API.   Currently what we have leaves nearly everything with respect to eviction, expiry, loaders, writes and in some cases listeners open to interpretation.   While this is reasonable for a Data Grid or lossless Cache solution, for pure Caching, which is what this API is all about, it makes things difficult for developers and implementors.   Basically for a specification to be incomplete in these areas it's a bit undesirable.  Without well defined semantics we can't write an RI (even if it's optional).  This means we can't produce a TCK for this feature.  Again, what we have is really good.   It's just along the way we've discovered a number of questions that need to be answered and we don't yet have those answers.

Personally speaking I'd like to have this feature in a Caching specification.  I know it's not a panacea or a solution for all consistency use-cases, but for those that it is, I can see how it would work very well.   

ASIDE: I've implemented Local Transactions wrappers for a few off-the-shelf Caches as part of trading platforms so I know that they are useful in certain use-cases.

At this point in time we have to be honest with ourselves in that;

a). It truly requires a big investment to answer many of the fundamental questions we have outstanding.  This is not a few days of remote work, but as we've seen, it's going to be weeks of face to face work, plus months of discussions and conversations, not to mention the documentation, development and testing requirement.   As Greg and I know, these things take an enormous amount of time and I'm not sure we are ready or need to invest that time right now.

b). Given that an extremely small population of developers architecturally consider "transactional caching" as option in their applications and even fewer actually try to use it (as Greg points out and I completely concur with from the Coherence perspective), the thought of delaying JSR-107 because of an incomplete optional feature is a bit worrying.   We only have to consider the really popular caching technologies being lapped up by the market (not naming names ;) and it's clear that transactional capabilities aren't required for mass adoption.   JSR-107, without transactions (at the moment) would provide a compelling use-case for almost all applications as it currently stands.

c). Looking at how the API is currently defined, there seems to be no real requirement for API changes (with the exception of configuration).   Implementations that want to support either local and/or XA can do so now (even with transactions removed).   Developers would only need to configure the implementation itself and fundamentally speaking, I think you'd need to do this anyway.   I'm going to write a post on how this would work - ie: how we could remove the Transactions support but still allow implementations to provide transactional views of data through caches.  

We've made an enormous amount of progress wrapping up the core API for JSR-107 in the past few months.   Strategically I think we should move the definition of Transactions into the next release, wrap this release up and get everyone using (and promoting) it as soon as possible.

My votes:

1. Remove Transactions from the Spec  (Brian Oliver's suggestion)

+1 

Remove for this release but to be resolved immediately in the next release!

2. Make XA and Local Transactions separate Optional Features (Bill Shannon's suggestion)

+1 (in the next release)

I think this is a must for Java EE integration.  Like what JMS offers, I think it would be beneficial to both implementors and developers as they can implement/use transactions without a container.   

3. Make each of the isolation modes optional, so that an implementation can say which it has.

-1 

I think at least one of level of isolation should be mandatory.  Making everything optional defeats the purpose of having a specification.

Regards

-- Brian

[Chris Dennis]

+1 from me as EG member, with the backing of Ludovic Orban and Alex Snaps at Terracotta.

[Chris Dennis]

Ugh +1 to removal of transactions, don't try and compose email while in meetings…

[Brian Martin]

My votes
1. +1 - work on this more completely in the future
2. +1 - per (1), optionally add this in the future
3.  0 - I think we need to carefully look at the supported isolation modes as part of 1.

Brian K. Martin
IBM Distinguished Engineer, Websphere XS and DataPower XC10 Chief Architec

[ben.c...@alumni.rutgers.edu]

Brian,   Thanks for this response.  As you point out, we should indeed delay the specification of transactional caching in this release.  We have made great progress wrt to designing a sound complete API to accommodate a Pure Cache.  As much as I want/need a standard to accommodate the notion of a Transactional Cache, it simply a fact that a Transactional Cache is not a Pure Cache.  A transactional Cache is an applied Cache.

Indeed, lets not let a potential applied Caching use case hold us back.  We are not ready to specify this application.  Lets do it for the next release.  Despite the sound/complete *interface* work delivered by Greg and Ludovic, the *semantics* need more clarity wrt to full API interoperabikity.  It is a hard problem, and we can give it the semantic rigor it deserves in JCache 2.0 ....

+1 remove initial spec 

+1 for next release

-1. Hell no!  For next release we deliver ALL isolations as MANDATORY. To not do so is just plain lazy and simple.

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "jsr107" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr107+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Aleksandar Seovic]

1. Remove Transactions from the Spec  (Brian Oliver's suggestion)

+1 -- I always thought transactions should be defined as part of the data grid spec (if that one is still alive) and have no place in the caching spec.

2. Make XA and Local Transactions separate Optional Features (Bill Shannon's suggestion)

-0 -- Again, it makes more sense to do this within the data grid spec, but if there is no such thing we could do it in v2

3. Make each of the isolation modes optional, so that an implementation can say which it has.

-1 -- This would be very confusing for the users and make the spec esentially non-portable. We should either do it properly or not do it at all.

[galderz]

Red Hat's vote is:

1. +1

2. -1

3. -1?

Cheers,

[Chris Dennis]

Today is not my day for following simple instructions it seems.  Just for the record:

1. +1
2. -1
3. -1

On 8/29/13 10:18 AM, "Chris Dennis" <chris.w...@gmail.com> wrote:

Ugh +1 to removal of transactions, don't try and compose email while in meetings…

On 8/29/13 10:15 AM, "Chris Dennis" <chris.w...@gmail.com> wrote:

+1 from me as EG member, with the backing of Ludovic Orban and Alex Snaps at Terracotta.

[Yannis Cosmadopoulos]

To be clear

1. +1
2. -1
3. -1

[Greg Luck]

Steve

Brian and I would like to reach a conclusion on the approach next Tuesday 3 September. So by all means take your time. I recommend reading  https://github.com/jsr107/jsr107spec/issues/153 after you read the Spec Chapter so that you get a feel for the issues being raised. 

Regards

Greg Luck

web: http://gregluck.com

skype: gregrluck

yahoo: gregrluck

mobile: +61 408 061 622

On 29/08/2013, at 6:56 PM, Steve Millidge <smil...@c2b2.co.uk> wrote:

Hi Greg,

 

What’s the time frame for the vote? I need to reread the section again and the arguments.

 

Steve Millidge
C2B2
The Leading Independent Middleware Experts. 
T: 08450 539457 |M: 07920 100626 |W: www.c2b2.co.uk | E: smil...@c2b2.co.uk
---------------------------------------------------------------------------------------------------------------
C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ
Registered in England and Wales: 4563419, Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire

 

From: jsr-107-e...@jcp.org [mailto:jsr-107-eg-bo...@jcp.org] On Behalf Of Greg Luck
Sent: 29 August 2013 05:11
To: jsr...@googlegroups.com; Java Community Process JSR #107 Expert List
Subject: [jsr-107-eg] Please vote on some Transactions Options for JSR107

 

[David Mossakowski]

1. +1 for now it's ok but I think it must be part of the spec eventually, how would depending on outside transaction wrapper enforce that all clients use it?

2. -1
3. -1

[Brian Oliver]

Just to quickly answer your question:

... I think it must be part of the spec eventually, how would depending on outside transaction wrapper enforce that all clients use it?

Sorry for any confusion.  I was simply commenting on the fact that it's possible to create a wrapper that provides last-only resource capabilities with in a transaction.  We did this for an application that required cache consistency with a single database.   However this wouldn't be the approach for JSR-107 (unless an implementation choose to provide the capabilities that way).   

Looking at the examples in the transactions chapter it's clear that there are no changes or transaction specific methods require for a Cache to be part of a transaction.   (unlike JMS etc).  Ultimately if a Cache supports being part of a transactions is an implementation and thus configuration detail.   

Moving forward what we need to do is resolve the outstanding semantic questions about eviction, expiry, loaders and writers, within the context of Java EE and non-Java EE environments, using Local v's XA transactions.   Once we do this I think we're good to go!

In the meantime I don't think there's a problem with an implementation providing Caches that interact with a transaction manager.   They would simply be viewed as an implementation specific extension/configuration, which is would obviously be permitted.

Hope this helps?

-- Brian

[Ryan Gardner]

1. +1

2. -1

3. -1

[Bongjae Chang]

My votes

1. +1 - move the definition of Transactions into the next release. 

2. +1 - also, into the next release.

3. 0

Regards,

Bongjae Chang