Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1066272

Summary: Isolation level description is not clear enough
Product: [JBoss] JBoss Data Grid 6 Reporter: Takayoshi Kimura <tkimura>
Component: DocumentationAssignee: Misha H. Ali <mhusnain>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: jdg-bugs, mgencur, rvansa, ttarrant
Target Milestone: ER4   
Target Release: 6.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Build Name: 22548, Administration and Configuration Guide-6.2-3 Build Date: 07-02-2014 10:56:40 Topic ID: 5341-563408 [Specified]
Last Closed: 2014-07-21 02:14:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Takayoshi Kimura 2014-02-18 07:52:57 UTC
Title: About Isolation Levels

Describe the issue:

> READ_COMMITTED. This is the default isolation level because it is applicable to a wide variety of requirements. 

The default is diffrent between library and client-server modes. In library mode the default is READ_COMMITTED. In client-server <locking> element the default is REPEATABLE_READ.

Also in JDG 6.2 client-server mode, we should put a note that it doesn't support REPEATABLE_READ so users always need to specify <locking> with READ_COMMITTED explicitly.

Additional information:

REPEATABLE_READ is not supported in Remote Client-Server Mode
https://bugzilla.redhat.com/show_bug.cgi?id=1066270

Comment 3 Martin Gencur 2014-05-19 07:46:50 UTC
I've looked at the configuration files in JDG 6.3 and didn't see REPEATABLE_READ anywhere. The default value was READ_COMMITTED everywhere. The topics should be changed accordingly.

Comment 4 Takayoshi Kimura 2014-05-19 07:51:15 UTC
The REPEATABLE_READ is "implicit" default value. The "shipped" default value is READ_COMMITTED. If you remove the <locking> it's locking=REPEATABLE_READ and doesn't work in this case.

Comment 5 Martin Gencur 2014-05-19 08:55:05 UTC
Had a chat with Tristan about this. The default value for locking is REPEATABLE_READ only if <locking> element is present in the configuration file and isolation is not specified. 
If the <locking> element is not present at all, the default is READ_COMMITTED.
This is confusing and we will make it default to READ_COMMITTED in all cases soon.

Comment 7 Radim Vansa 2014-05-21 07:50:34 UTC
The description for isolation level when using transactions is clear, however, I miss any information about the impact on non-transactional cache (which is always the case for remote client-server mode).

Besides that, I think that the whole "16. Set Up Isolation Levels" chapter should go before "14. Locking" and it is referenced multiple times from the preceding chapters, without describing what the isolation level is.

Comment 8 Martin Gencur 2014-05-21 13:30:17 UTC
Misha,
there's already a pull request at https://github.com/mgencur/infinispan/commit/96fef932f8122ba9df3303b72dc6b288ccd0be98
This won't make it into Beta but should be ready for GA.

The changes are following:
- the default isolation level for server mode in all cases will be READ_COMMITTED
- there won't be a possibility to set a different isolation level (so "isolation" attribute will be ignored and a warning thrown)
- also, transactions will be disabled by default (which is also true now) and it <transaction> tag in configuration will be ignored and a warning thrown

So not sure whether we want to have the documentation ready for GA now or it has to be aligned with functionality that is in Beta (in which case I would just revert all the recent changes).

Comment 14 Misha H. Ali 2014-06-16 05:33:14 UTC
I mentioned this to Tristan since perhaps he can help with the third bit (transactions). Flagging Martin to request QE for 1 & 2 and advice about 3, if possible.

Comment 18 Tristan Tarrant 2014-06-25 09:54:28 UTC
C) locking is its own element 

<locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>

F) +1 to removal

Comment 25 Martin Gencur 2014-06-30 07:32:11 UTC
I think it looks good now. Thanks for fixing it.

Comment 26 Misha H. Ali 2014-07-21 02:14:40 UTC
Now available on access.redhat.com under the JBoss Data Grid 6.3 documentation label.