[JBoss JIRA] Created: (ISPN-1345) Dirty reads may occurs on mutable objects
by Christophe Labouisse (JIRA)
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
12 years, 1 month
[JBoss JIRA] Created: (ISPN-1213) TreeCache expires parents that have children
by Todd Ciezadlo (JIRA)
TreeCache expires parents that have children
--------------------------------------------
Key: ISPN-1213
URL: https://issues.jboss.org/browse/ISPN-1213
Project: Infinispan
Issue Type: Bug
Components: Eviction
Affects Versions: 4.2.1.FINAL
Reporter: Todd Ciezadlo
Assignee: Manik Surtani
TreeCache parents expire according to the max-idle value even if they contain children. This puts the tree cache in an inconsistent state since the "dangling" children can be retrieved through TreeCache.get(FQN, String) calls, but cannot be traversed to through TreeCache.getRoot() and Node.getChildren() calls.
Copied a unit test to Steps to Reproduce.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by Paul Ferraro (JIRA)
Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
-------------------------------------------------------------------------
Key: ISPN-761
URL: https://jira.jboss.org/browse/ISPN-761
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.BETA1
Reporter: Paul Ferraro
Assignee: Manik Surtani
Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
I think CacheLoaderInterceptor needs to implement the following methods:
Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-791) On node startup, ensure all peers have compatible configurations
by Manik Surtani (JIRA)
On node startup, ensure all peers have compatible configurations
----------------------------------------------------------------
Key: ISPN-791
URL: https://jira.jboss.org/browse/ISPN-791
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Affects Versions: 4.1.0.Final
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.0.0.BETA1, 5.0.0.Final
This is to prevent caches that are supposed to be symmetric/identical from being misconfigured. Some elements are allowed to be unique, of course, such as bind addresses in JGroups as well as node names, server hints, certain props passed to cache stores, etc.
A simple test could be a hash (MD5 or SHA1?) of the config XML (or a serial form of the generated Configuration bean) which is exchanged as a part of the join method. On failure of the hash check, the entire object could be checked, and if that fails as well, an appropriate ConfigurationException could be thrown.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (ISPN-201) make JDBC cache store use DB transactions for commit/rollback
by Mircea Markus (JIRA)
make JDBC cache store use DB transactions for commit/rollback
-------------------------------------------------------------
Key: ISPN-201
URL: https://jira.jboss.org/jira/browse/ISPN-201
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.0.0.GA
current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month