3:29 p.m.
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 returned printed on step 7 should
be 42, as the setting to 666 is not committed yes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:31 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
SBS JIRA Integration updated ISPN-1345:
---------------------------------------
Forum Reference: http://community.jboss.org/message/622401#622401,
http://community.jboss.org/message/622455 (was:
http://community.jboss.org/message/622455)
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 returned printed on step 7
should be 42, as the setting to 666 is not committed yes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:35 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Christophe Labouisse updated ISPN-1345:
---------------------------------------
Forum Reference: http://community.jboss.org/message/622401#622401 (was:
http://community.jboss.org/message/622401#622401,
http://community.jboss.org/message/622455)
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 returned printed on step 7
should be 42, as the setting to 666 is not committed yes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:05 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
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
10:57 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani commented on ISPN-1345:
-------------------------------------
Try setting storeAsBinary to true in your configuration
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
11:05 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1345:
--------------------------------
Fix Version/s: 5.1.0.ALPHA1
5.1.0.FINAL
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
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
11:20 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Christophe Labouisse commented on ISPN-1345:
--------------------------------------------
I changed the cache creation to:
{code}
cacheManager = new DefaultCacheManager();
cacheManager.getDefaultConfiguration().fluent().storeAsBinary().transaction().cacheStopTimeout(5000);
final Configuration config = new
Configuration().fluent().transactionManagerLookup(this.tmLookup).locking()
.isolationLevel(IsolationLevel.READ_COMMITTED).storeAsBinary().build();
{code}
It didn't change anything.
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
11:28 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1345) Dirty reads may occurs on mutable objects
[
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
12:27 p.m.
New subject: [JBoss JIRA] Commented: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani commented on ISPN-1345:
-------------------------------------
Yes, I am working on a similar scheme, to be compliant with some recent developments in
JSR 107. As you say, it will involve:
* No copying for known immutable types
* No copying for POJOs annotated with @Immutable
* Otherwise, copy on write. (Not on read).
But this is work in progress.
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
6:10 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1345:
--------------------------------
Fix Version/s: 5.1.0.ALPHA2
(was: 5.1.0.ALPHA1)
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
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
7:16 p.m.
New subject: [JBoss JIRA] Commented: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani commented on ISPN-1345:
-------------------------------------
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
7:18 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (ISPN-1345) Dirty reads may occurs on mutable objects
[
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
11:37 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1345:
--------------------------------
Fix Version/s: 5.1.0.BETA1
(was: 5.1.0.ALPHA2 )
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
Fix For: 5.1.0.BETA1, 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
2:34 p.m.
New subject: [JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1345:
-----------------------------------
Fix Version/s: 5.1.0.BETA2
(was: 5.1.0.BETA1)
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.BETA2, 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:24 a.m.
New subject: [JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1345:
-----------------------------------
Fix Version/s: 5.1.0.BETA3
(was: 5.1.0.BETA2)
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.BETA3, 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:32 a.m.
New subject: [JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1345:
--------------------------------
Fix Version/s: 5.2.0.FINAL
(was: 5.1.0.FINAL)
(was: 5.1.0.BETA3)
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
Fix For: 5.2.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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:10 p.m.
New subject: [JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Lucas Vella commented on ISPN-1345:
-----------------------------------
Not copying on read may lead to the problem I mention in:
https://community.jboss.org/thread/201564
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.2.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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:38 p.m.
New subject: [JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
reiner maia commented on ISPN-1345:
-----------------------------------
I am having the same problem
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.2.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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:27 p.m.
New subject: [JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
[
https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-1345:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.2.0.Final)
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: 6.0.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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4188
days inactive
4622
days old
infinispan-issues@lists.jboss.org
18 comments
8 participants
participants (8)
-
Christophe Labouisse (JIRA) -
Galder Zamarreño (Updated) (JIRA)
-
Lucas Vella (JIRA)
-
Manik Surtani (JIRA)
-
Manik Surtani (Updated) (JIRA)
-
Mircea Markus (JIRA)
-
reiner maia (JIRA)
-
SBS JIRA Integration (JIRA)