[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1345) Dirty reads may occurs on mutable objects

Christophe Labouisse (JIRA) jira-events at lists.jboss.org
Thu Aug 25 05:28:17 EDT 2011


    [ https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623950#comment-12623950 ] 

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

        


More information about the infinispan-issues mailing list