[
https://issues.jboss.org/browse/ISPN-1188?page=com.atlassian.jira.plugin....
]
Manik Surtani commented on ISPN-1188:
-------------------------------------
It should be logged that the isolation level has been upgraded or downgraded at startup,
and the correct isolation level is set. It isn't treated as an error since upgrading
isolation levels is common practice with databases, and providing "greater"
consistency can never be harmful to an application. The only potential problem is
downgrading, which happens if SERIALIZABLE is used. In this case, it is logged and
downgraded, but this is generally very rare since very few, if any, apps use SERIALIZABLE
since it is such a large performance penalty in databases, etc.
config schema - isolationLevel attribute allows unsupported isolation
modes
---------------------------------------------------------------------------
Key: ISPN-1188
URL:
https://issues.jboss.org/browse/ISPN-1188
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 5.0.0.CR5
Reporter: Michal Linhard
Assignee: Manik Surtani
The configuration schema, attribute infinispan.configuration.locking.isolationLevel
allows picking of two unsupported isolation levels
READ_UNCOMMITTED
SERIALIZABLE
We don't even warn when such isolation type is used - in the code we use tests like:
useReadCommitted = configuration.getIsolationLevel() == IsolationLevel.READ_COMMITTED;
useRepeatableRead = configuration.getIsolationLevel() == IsolationLevel.REPEATABLE_READ;
shouldn't we remove these from schema to avoid confusion ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira