Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


How to Provide Different Consistency Options #54

gregrluck opened this Issue · 10 comments

5 participants


The problem is:

1) Caches like Ehcache have different consistency options.
2) We do not want to enumerate all of these in the spec because their might not be common agreement on them
3) The TCK currently only works with strong consistency
4) We have advice from PMO/EE7 that it is not Ok to simply honour strong and allow the others but without the spec saying anything. The spec has to allow the behaviour.
5) We do not want to end up with a spec that only supports strong consistency.

See below for discussion.

Patrick's right, all the behavior of the JCP-defined APIs in the product has to be as required or allowed by the spec.

If the spec says "this API does X", then it has to always do X, no matter how you configure the product.

If, as you suggest, the spec allows consistency modes that are different than what the spec defines, there should be a standard way for applications to get the mode that the spec does define. The TCK should be written to use that mode. If the way to choose the mode is not standardized (a bad idea, in my opinion), we'll need to add a special TCK compatibility rule that allows the TCK to always be run in a mode that provides the spec-defined consistency, and I would strongly suggest that the spec require the default mode (if such a thing makes sense) to provide the spec defined behavior.

A key attribute of our Java compatibility program has been to prevent the typical vendor "bait and switch" where they claim to conform to the standard, but the product really only works in the standard way if you configure it specially. If you're "Java compatible", we want you to always be Java compatible.

Patrick Curran wrote on 02/03/12 11:52:
Hello, Greg:

Normally I would refer questions like this to the Spec Lead, but since that's you I guess this wouldn't help very much :)

In future, it would be helpful if you could use the address for queries such as this, to ensure that you'll get an answer even if Harold is away.

As for your questions, see my responses inline below.

-------- Original Message --------
Subject: Please respond - question on defaults for TCK tests
Date: Fri, 3 Feb 2012 08:53:30 +1000
From: Greg Luck
To: Harold Ogle
CC: Yannis Cosmadopoulos, Chris Dennis

We are planning on having our product defaults not pass the TCK. To pass the TCK we would need to set a system property called say "jsr107.compliance.mode=true".
One example is on consistency. Out of the box our default is eventual consistency. But to pass the TCK we will need to use our strong consistency setting.

Is that Ok? And don't give your whatever you like answer. I have found that as Oracle is co copyright owner and this is also EE 7 they have stricter rules than the JCP.

Please advise.

I'm sure you really know the answer to this question :)

Of course this isn't OK. All implementations must be compatible. This means not only passing the TCK, but meeting all of the other compatibility requirements that are specified in the TCK User's Guide. One of those requirements is that implementations must be compatible "in all modes," which means that you can't play games with switches in the manner you're suggesting.

On a second point, is it Ok to say things like "Implementations may support additional consistency models". i.e. it is not in the spec but we are foreshadowing that this is an area where we expect implementations to add additional modes.
If you mean is it OK for the spec to say that "Implementations may support additional consistency models" - absolutely. The purpose of the spec is not only to define what is required, but also to specify where implementations are free to innovate.


It seems to me that what we need to add to cover this is to add support for configurable consistency modes:

CacheBuilder<K, V> CacheBuilder.setConsistency(Consistency mode);

Consistency CacheConfiguration.getConsistency();

enum Consistency {

STRONG consistency would map to the currently understood set of Cache behaviors. None would basically support no guarantees at all. There would be no default defined by the standard so implementations would be entitled to choose their own default appropriately and users wanting an explicit setting (e.g. the TCK) would have to explicitly choose one - or rely on explicit knowledge of their chosen implementation. We can document NONE to stress that implementors are encouraged to provide stronger guarantees as appropriate for their own implementation, and that users using this level are encouraged to consult with their chosen implementation's documentation to confirm what additional guarantees it provides.

This would serve as a starting off point. From here we can introduce additional well defined consistency modes that lie on the spectrum between none and strong. This may happen before 1.0 is released or in a subsequent dot release of the standard. Consistency is one area in which I anticipate much evolution in terms of what is and isn't considered acceptable by users in the future. This is why I think NONE is a useful concept it future proofs the standard against shifting user expectations.


+1 to both Chris' suggestion and Greg's follow-up. I think the STRONG/NONE enum would work well and it would be easy enough to tweak the TCK to always set STRONG consistency for tests.


I am fine with the principle of configurable consistency levels. Two issues
1) I don't think we should use an enum as that restricts possible allowed values.
2) I have some doubts we can define NONE suitably but am happy yto defer judgement till I see the attempt


It could be changed from an enum to an object with some supplied constants similar to what the portlet spec does:

public final class Consistency implements Serializable {
    public static final Consistency STRONG = new Consistency("STRONG");

    private final String consistency;

    public Consistency(String consistency) {
        this.consistency = consistency.toUpperCase();

    //equals/hashcode just compare the consistency field

That would allow custom consistency modes to be specified and client code to actually use those modes without resorting to a vendor-specific API. We would also only need to define STRONG as any other mode would be unknown to the spec.

The spec doc would require that all implementations support STRONG and then we update the TCK to set STRONG for all of the tests.


This is pretty much exactly what I was suggesting.
1) relace enum with something else - the class above is perfectly adequate for the task
2) define just STRONG for the spec


The final class solution does indeed make more sense - I'm happy with that. I need to think more about the implications of not defining "NONE" in the spec. The only concern I have with it is that the statement that there is no spec defined default consistency value seems more alien when there is only one spec defined value - it maybe feels more like we are gaming the JCP rules. Does that make sense?


I think a set of 1 is defensible because we believe other modes may be possible/desirable in the future but we are not ready to specify them at present.


I actually don't like the final class proposition above. There are a couple of reasons for this:

  • What's the value of it over String ? I just miss what it provides over a plain String, except easing users life by pointing them to "some" javadoc (which will doc only STRONG, and point to implementors javadoc for other values)
  • When an implementor lets me use the new Consistency("eventual"), it just silently bound me to its implementation. Not only that but, especially when in maintenance, there is an implicit dependency to a specific provider that might proove hard to resolve for a developer looking at the code. Especially as eventual might have fundamental different meanings for different providers (should the they use the same name, i.e. String).

I think what we actually are trying to achieve here, is having a way for users to configure a cache in a implementor specific way. Which makes sense, but I firmly believe this should be as explicit as possible. Not sure how the spec was planning on letting users do this, but maybe the same approach should be used for this very example. This would still leave the spec with two possible values for the consistency level: STRONG (spec'ed) and NONE (or unspecified, unknown, but certainly unspec'ed); the reason for the latter being the getter on CacheConfiguration. Again, for more details, some specific cast (or other hook to access the implementor specific cache config) would be required. Using ProviderConsistency.STRICT on the implemntor's specific builder might still result in CacheConfiguration.getConsistency() returning STRONG, if ProviderConsistency.STRICT matches jsr107 definition of Consistency.STRONG.

If using explicit casts would be the way to get to implementor specific features and extensions, one would set to "eventual consistency" like so: (these are just examples for clarification, not a proposal on how to do vendor specific configs or anything the like!)

((EhcacheBuilder) cacheBuilder).setDistributedConsistency(EhcacheConsistency.EVENTUAL) // this would override any previous use of javax.cache.CacheBuilder.setConsistency 
cache.getConfiguration().getConsistency() == Consistency.NONE // Unspec'ed
((EhcacheConfiguration) cache.getConfiguration()).getConsistency() == EhcacheConsistency.EVENTUAL


((EhcacheBuilder) cacheBuilder).setEhcacheConsistency(EhcacheConsistency.STRICT) // Imagine STRICT is our version of JSR107's STRONG
cache.getConfiguration().getConsistency() == Consistency.STRONG
((EhcacheConfiguration) cache.getConfiguration()).getEhcacheConsistency() == EhcacheConsistency.STRICT

Also this raises the question of whether implementors can treat this call as they want :

@gregrluck gregrluck was assigned

The interface now says in the end of the Consistency section.

Further Consistency Modes

  • An implementation may support additional consistency models.
@gregrluck gregrluck closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.