[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Christophe Labouisse commented on ISPN-1345:
--------------------------------------------
After some brainstorming on the subject I guess the fix will probably need to perform some
copy on read/write when getting or putting objects into the cache. Ehcache seems to
perform a copy each time an object is retrieved (an probably put) from the cache (at least
in a simple _defaultish_ transactional configuration). As this will involves copy and
sometime serialization, it could hinder performances severely.
So I guess a fix should include some level of configuration in order to keep the current
mechanism when the stored objects are known to be immutable, or enable a copy mechanism
based on the marshalling system.
_#my two cents_
Dirty reads may occurs on mutable objects
-----------------------------------------
Key: ISPN-1345
URL:
https://issues.jboss.org/browse/ISPN-1345
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.0.0.FINAL
Environment: Windows Java 1.6.0_26
Reporter: Christophe Labouisse
Assignee: Manik Surtani
Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL
In local mode, I create a cache like this:
{code}
cacheManager = new DefaultCacheManager();
cacheManager.getDefaultConfiguration().fluent().storeAsBinary().transaction().cacheStopTimeout(5000);
final Configuration config = new
Configuration().fluent().transactionManagerLookup(this.tmLookup).locking()
.isolationLevel(IsolationLevel.READ_COMMITED).build();
this.cacheManager.defineConfiguration("Gruik", config);
this.cache = this.cacheManager.getCache("Gruik");
{code}
When retrieving data using {{cache.get(_key_)}} I find out that Infinispan returns the
object instance actually stored in the cache datastore. This is OK when the inserted
objects are immutable but fails to achieve isolation when using mutable objects.
For instance on a simple Pojo with a {{get/setValue}}.
||Step||Reader||Writer||
|1|Starts transaction| |
|2|{{value = cache.get(KEY);}}| |
|3|{{System.out.println(value.getValue());}} Prints 42| |
|4| |Starts transaction|
|5| |{{value = cache.get(KEY);}} Same instance than step 2|
|6| |{{value.setValue(666); // Prepare update}}|
|7|{{System.out.println(value.getValue());}} Prints 666 !| |
|8|{{value = cache.get(KEY);}} Same instance than step 2| |
|9| |{{cache.put(KEY,value);}}|
|10| |Commits transaction|
|11|{{value = cache.get(KEY);}} Same instance than step 2| |
|12|{{System.out.println(value.getValue());}} Prints 666| |
|13|Commits transaction| |
According to the READ_COMMITTED specification, the value printed on step 7 should be 42
as the change to 666 is not committed yet.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira