[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani edited comment on ISPN-1345 at 9/16/11 1:17 PM:
--------------------------------------------------------------
There should also be a {{copyOnRead}} and {{copyOnWrite}} boolean flag to enable copy (via
serialization) on each read/write to properly protect against the use case above. Both
would be {{false}} by default, and would imply {{storeAsBinary}} is {{true}} for values
(not for keys).
was (Author: manik):
There should also be a "copyOnWrite" boolean flag to enable copy (via
serialization) on each write.
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.ALPHA2 , 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