[JBoss JIRA] (ISPN-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-1822:
--------------------------------
Fix Version/s: 5.3.0.Final
> Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-1822
> URL: https://issues.jboss.org/browse/ISPN-1822
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.1.0.FINAL
> Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1))
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ;
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxi3270-20110827_01)
> IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled)
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 5.2.1, 5.3.0.Final
>
>
> This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot.
> Steps to reproduce the problem:
> 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU
> 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory)
> 3) call cache.get("key1")
> 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter)
> I'll shortly issue a pull request with a test to ispn-core
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-1100) TransactionLogger Not Unlocked/Disabled
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1100?page=com.atlassian.jira.plugin.... ]
Mircea Markus closed ISPN-1100.
-------------------------------
Resolution: Out of Date
> TransactionLogger Not Unlocked/Disabled
> ---------------------------------------
>
> Key: ISPN-1100
> URL: https://issues.jboss.org/browse/ISPN-1100
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 4.2.1.FINAL
> Reporter: Shane Johnson
> Assignee: Manik Surtani
>
> If rehashing is DISABLED, the transaction logger is NOT unlocked and disabled for sender / receivers.
> Typically the process is as follows:
> 1) Enable the transaction logger. (DistributionManagerImpl.rehash)
> 2) Submit InvertedLeaveTask. (DistributionManagerImpl.rehash)
> 3) Block new transactions if this is a receiver. (InvertedLeaveTask.performRehash)
> 4) Process / Drain transaction log if this is a sender. (InvertedLeaveTask.performRehash)
> 5) Unblock new transactions if this is a receiver.
> The problem is that step 4 is only performed if rehashing is enabled. This is the step that eventually unlocks and disables the transaction logger.
> Our temporary fix was to add an 'else' block that called 'processAndDrainTxLog'.
> if (configuration.isRehashEnabled()) {
> ...
> }
> else {
> processAndDrainTxLog(oldCH, newCH, replCount);
> }
> So far, it seems to be working. Our cluster is stable.
> Of note is that we did not keep the 'isSender' check. When we used it, the transaction log remained enabled on any node that was ONLY a receiver.
> I suspect this is because during a standard rehash the RemoteTransactionLogger sends a RehashControlCommand that ultimately unlocks and disables the transaction logger? This would place the responsibility on the sender and ensure that ALL receivers do so.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-1089) NullPointerException when using an AtomicMap without a TransactionManagerLookup setup
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1089?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-1089:
--------------------------------
Fix Version/s: 5.3.0.Final
> NullPointerException when using an AtomicMap without a TransactionManagerLookup setup
> -------------------------------------------------------------------------------------
>
> Key: ISPN-1089
> URL: https://issues.jboss.org/browse/ISPN-1089
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.0.0.CR1
> Reporter: Emmanuel Bernard
> Assignee: Manik Surtani
> Fix For: 5.3.0.Final
>
>
> {code}
> org.infinispan.CacheException: Unable to start batch
> at org.infinispan.batch.BatchContainer.startBatch(BatchContainer.java:84)
> at org.infinispan.batch.AutoBatchSupport.startAtomic(AutoBatchSupport.java:44)
> at org.infinispan.atomic.AtomicHashMapProxy.put(AtomicHashMapProxy.java:160)
> at org.hibernate.ogm.type.descriptor.PassThroughGridTypeDescriptor$1.doBind(PassThroughGridTypeDescriptor.java:41)
> at org.hibernate.ogm.type.descriptor.BasicGridBinder.bind(BasicGridBinder.java:73)
> at org.hibernate.ogm.type.AbstractGenericBasicType.nullSafeSet(AbstractGenericBasicType.java:275)
> at org.hibernate.ogm.type.AbstractGenericBasicType.nullSafeSet(AbstractGenericBasicType.java:270)
> at org.hibernate.ogm.persister.OgmEntityPersister.createNewResultSetIfNull(OgmEntityPersister.java:875)
> at org.hibernate.ogm.persister.OgmEntityPersister.insert(OgmEntityPersister.java:859)
> at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79)
> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:184)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383)
> at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133)
> at org.hibernate.ogm.test.embeddable.EmbeddableTest.testEmbeddable(EmbeddableTest.java:48)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.hibernate.testing.junit.functional.annotations.HibernateTestCase.runTest(HibernateTestCase.java:97)
> at org.hibernate.testing.junit.functional.annotations.HibernateTestCase.runBare(HibernateTestCase.java:85)
> at com.intellij.junit3.JUnit3IdeaTestRunner.doRun(JUnit3IdeaTestRunner.java:109)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:60)
> Caused by: java.lang.NullPointerException
> at org.infinispan.batch.BatchContainer.startBatch(BatchContainer.java:65)
> ... 37 more
> {code}
> A more descriptive exception would be nice. I did not have any NPE until I started to use AtomicMaps in Hibernate OGM. I now set a TransactionManagerLookup and it works.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-962) Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-962?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-962:
-------------------------------
Assignee: Dan Berindei (was: Manik Surtani)
> Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
> ------------------------------------------------------------------------
>
> Key: ISPN-962
> URL: https://issues.jboss.org/browse/ISPN-962
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 4.2.0.Final
> Reporter: Shane Johnson
> Assignee: Dan Berindei
> Labels: Invalidation, Rehash
>
> If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container.
> The problem is in the commitEntry method.
> boolean doCommit = true;
> if (!dm.isLocal(entry.getKey())) {
> if (configuration.isL1CacheEnabled()) {
> dm.transformForL1(entry);
> } else {
> doCommit = false;
> }
> }
> if (doCommit)
> entry.commit(dataContainer);
> else
> entry.rollback();
> For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation.
> We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true.
> To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-962) Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-962?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-962:
-------------------------------
Fix Version/s: 5.2.1
5.3.0.Final
> Entries not committed w/ DistLockingInterceptor and L1 caching disabled.
> ------------------------------------------------------------------------
>
> Key: ISPN-962
> URL: https://issues.jboss.org/browse/ISPN-962
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Locking and Concurrency
> Affects Versions: 4.2.0.Final
> Reporter: Shane Johnson
> Assignee: Dan Berindei
> Labels: Invalidation, Rehash
> Fix For: 5.2.1, 5.3.0.Final
>
>
> If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container.
> The problem is in the commitEntry method.
> boolean doCommit = true;
> if (!dm.isLocal(entry.getKey())) {
> if (configuration.isL1CacheEnabled()) {
> dm.transformForL1(entry);
> } else {
> doCommit = false;
> }
> }
> if (doCommit)
> entry.commit(dataContainer);
> else
> entry.rollback();
> For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation.
> We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true.
> To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2789) OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2789?page=com.atlassian.jira.plugin.... ]
Anna Manukyan commented on ISPN-2789:
-------------------------------------
Thanks a lot, [~sannegrinovero] . Yes I know about the conflict. That's why I'm waiting for your pull request to be integrated, so that I can integrate it with my branch and then pull.
> OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
> -----------------------------------------------------------------
>
> Key: ISPN-2789
> URL: https://issues.jboss.org/browse/ISPN-2789
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> In case when calling LuceneCacheLoader.loadAll() method, the following exception appears:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.<init>(HashMap.java:204)
> at java.util.HashMap.<init>(HashMap.java:216)
> at java.util.HashSet.<init>(HashSet.java:142)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllEntries(DirectoryLoaderAdaptor.java:87)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:116)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAll(LuceneCacheLoader.java:105)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadEntries(LuceneCacheLoaderTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> I tried to edit VM options for make it to work, but even in case of high numbers for memory usage, this still happens.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-1345:
--------------------------------
Priority: Critical (was: Major)
> 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
> Priority: Critical
> Fix For: 5.3.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
13 years, 2 months
[JBoss JIRA] (ISPN-2794) undeploy of infinispan.war doesn't stop DefaultCacheManager
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2794?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2794:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1641
> undeploy of infinispan.war doesn't stop DefaultCacheManager
> -----------------------------------------------------------
>
> Key: ISPN-2794
> URL: https://issues.jboss.org/browse/ISPN-2794
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.2.0.Final
> Reporter: Michal Linhard
> Assignee: Tristan Tarrant
>
> 1.deploy infinispan.war
> 2.undeploy
> 3.deploy, and you'll get:
> {code}
> 09:41:43,436 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/infinispan]] (MSC service thread 1-1) Servlet /infinispan threw load() exception: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager"
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:101) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:95) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:63) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:705) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:300) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:139) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.rest.StartupListener.init(StartupListener.scala:57) [classes:]
> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:89) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
> The problem is that DefaultCacheManager created in ManagerInstance.instance still lives after undeploy.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-1345:
-------------------------------------
increased the priority given the high number of voters.
> 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
> Priority: Critical
> Fix For: 5.3.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
13 years, 2 months