[infinispan-issues] [JBoss JIRA] Updated: (ISPN-1345) Dirty reads may occurs on mutable objects
Christophe Labouisse (JIRA)
jira-events at lists.jboss.org
Wed Aug 24 14:05:18 EDT 2011
[ https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christophe Labouisse updated ISPN-1345:
---------------------------------------
Description:
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.
was:
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 returned printed on step 7 should be 42, as the setting to 666 is not committed yes.
Forum Reference: http://community.jboss.org/message/622401#622401 (was: http://community.jboss.org/message/622401#622401)
> 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
>
> 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
More information about the infinispan-issues
mailing list