Misleading places in cache related documentations

[Denis Magda]

Igniters,

I've faced with some confusing places in cache related documentations.
Before fixing it I want to be sure that my understanding is correct.

- CacheAtomicityMode.TRANSACTIONAL. There is a sentence saying:
/"However, cache * atomicity mode will be changed to {@link #ATOMIC}
starting from version {@code 5.2}, * so it is recommended that desired
atomicity mode is explicitly configured * instead of relying on default
value."
/In my understanding it's time to remove the sentence, correct?

- CacheConfiguration.getAtomicityMode() returns null if the mode wasn't
explicitly set. But this is not highlighted in the documentation.
I propose to initialize internal variable with DFLT_CACHE_ATOMICITY_MODE
at the time the CacheConfiguration instance is being created .
Is anyone knows a reason why we should initialization logic as is?

- CacheAtomicityMode.ATOMIC. There is a sentence: /"This mode is
currently implemented for {@link CacheMode#PARTITIONED} caches only."
/This seems to be an outdated info. I can easily create a replicated
cache with atomic mode.
Let's remove the sentence?

--
Denis

[dsetrakyan]

On Sat, Sep 19, 2015 at 12:11 PM, Denis Magda <[hidden email]> wrote:

> Igniters,
>
> I've faced with some confusing places in cache related documentations.
> Before fixing it I want to be sure that my understanding is correct.
>
> - CacheAtomicityMode.TRANSACTIONAL. There is a sentence saying: /"However,
> cache * atomicity mode will be changed to {@link #ATOMIC} starting from
> version {@code 5.2}, * so it is recommended that desired atomicity mode is
> explicitly configured * instead of relying on default value."
> /In my understanding it's time to remove the sentence, correct?
>

Agree, let's remove it.


>
> - CacheConfiguration.getAtomicityMode() returns null if the mode wasn't
> explicitly set. But this is not highlighted in the documentation.
> I propose to initialize internal variable with DFLT_CACHE_ATOMICITY_MODE
> at the time the CacheConfiguration instance is being created .
> Is anyone knows a reason why we should initialization logic as is?
>

I don't mind, but we must make sure whether the "null" value in
configuration gets a special treatment.


>
> - CacheAtomicityMode.ATOMIC. There is a sentence: /"This mode is currently
> implemented for {@link CacheMode#PARTITIONED} caches only."
> /This seems to be an outdated info. I can easily create a replicated cache
> with atomic mode.
> Let's remove the sentence?


Yes, let's remove it (this is very misleading).


>


> --
> Denis
>

[Denis Magda]

Applied these cosmetic changes.

Could anyone with commit rights apply the patch to 1.4 branch? It
doesn't make sense to create an issue and pull-request for such minor
changes.
The patch is attached.

--
Denis

On 9/19/2015 5:53 PM, Dmitriy Setrakyan wrote:

> On Sat, Sep 19, 2015 at 12:11 PM, Denis Magda <[hidden email]> wrote:
>
>> Igniters,
>>
>> I've faced with some confusing places in cache related documentations.
>> Before fixing it I want to be sure that my understanding is correct.
>>
>> - CacheAtomicityMode.TRANSACTIONAL. There is a sentence saying: /"However,
>> cache * atomicity mode will be changed to {@link #ATOMIC} starting from
>> version {@code 5.2}, * so it is recommended that desired atomicity mode is
>> explicitly configured * instead of relying on default value."
>> /In my understanding it's time to remove the sentence, correct?
>>
> Agree, let's remove it.
>
>
>> - CacheConfiguration.getAtomicityMode() returns null if the mode wasn't
>> explicitly set. But this is not highlighted in the documentation.
>> I propose to initialize internal variable with DFLT_CACHE_ATOMICITY_MODE
>> at the time the CacheConfiguration instance is being created .
>> Is anyone knows a reason why we should initialization logic as is?
>>
> I don't mind, but we must make sure whether the "null" value in
> configuration gets a special treatment.
>
>
>> - CacheAtomicityMode.ATOMIC. There is a sentence: /"This mode is currently
>> implemented for {@link CacheMode#PARTITIONED} caches only."
>> /This seems to be an outdated info. I can easily create a replicated cache
>> with atomic mode.
>> Let's remove the sentence?
>
> Yes, let's remove it (this is very misleading).
>
>
>
>> --
>> Denis
>>

[Denis Magda]

Got commiter rights and merged these minor changes to 1.4.

--
Denis

On 9/19/2015 9:32 PM, Denis Magda wrote:

> Applied these cosmetic changes.
>
> Could anyone with commit rights apply the patch to 1.4 branch? It
> doesn't make sense to create an issue and pull-request for such minor
> changes.
> The patch is attached.
>
> --
> Denis
>
> On 9/19/2015 5:53 PM, Dmitriy Setrakyan wrote:
>> On Sat, Sep 19, 2015 at 12:11 PM, Denis Magda <[hidden email]>
>> wrote:
>>
>>> Igniters,
>>>
>>> I've faced with some confusing places in cache related documentations.
>>> Before fixing it I want to be sure that my understanding is correct.
>>>
>>> - CacheAtomicityMode.TRANSACTIONAL. There is a sentence saying:
>>> /"However,
>>> cache * atomicity mode will be changed to {@link #ATOMIC} starting from
>>> version {@code 5.2}, * so it is recommended that desired atomicity
>>> mode is
>>> explicitly configured * instead of relying on default value."
>>> /In my understanding it's time to remove the sentence, correct?
>>>
>> Agree, let's remove it.
>>
>>
>>> - CacheConfiguration.getAtomicityMode() returns null if the mode wasn't
>>> explicitly set. But this is not highlighted in the documentation.
>>> I propose to initialize internal variable with
>>> DFLT_CACHE_ATOMICITY_MODE
>>> at the time the CacheConfiguration instance is being created .
>>> Is anyone knows a reason why we should initialization logic as is?
>>>
>> I don't mind, but we must make sure whether the "null" value in
>> configuration gets a special treatment.
>>
>>
>>> - CacheAtomicityMode.ATOMIC. There is a sentence: /"This mode is
>>> currently
>>> implemented for {@link CacheMode#PARTITIONED} caches only."
>>> /This seems to be an outdated info. I can easily create a replicated
>>> cache
>>> with atomic mode.
>>> Let's remove the sentence?
>>
>> Yes, let's remove it (this is very misleading).
>>
>>
>>
>>> --
>>> Denis
>>>
>