[JBoss JIRA] (ISPN-3422) In non-tx caches, write operations may not be atomic during rebalance
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3422?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3422:
--------------------------------
Labels: 620 630 nbst (was: 620 nbst)
> In non-tx caches, write operations may not be atomic during rebalance
> ---------------------------------------------------------------------
>
> Key: ISPN-3422
> URL: https://issues.jboss.org/browse/ISPN-3422
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, 630, nbst
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> If the cache topology changes while a write command is running and before it has actually committed the entry to the data container, we retry the command (see ISPN-3366 and ISPN-3357). But before we detect the topology change, one or more of the backup owners may have already applied the modification.
> Retrying the command re-acquires the key lock on the primary owner (even if the primary owner didn't change). That means another command could have modified the same key in the meantime, but the retried command is going to ignore any changes and is going to return the value before the first attempt. Obviously, the command is not retried if the first attempt is not successful, but scenarios like this are possible:
> {code}
> thread 1: putIfAbsent(k, v1) -> null
> thread 2: putIfAbsent(k, v2) -> null
> {code}
--
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
12 years
[JBoss JIRA] (ISPN-3498) Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3498?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3498:
--------------------------------
Labels: 620 630 (was: 620)
> Cannot construct org.infinispan.util.KeyValuePair as it does not have a no-args constructor
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-3498
> URL: https://issues.jboss.org/browse/ISPN-3498
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 6.0.0.Alpha4
> Environment: Azul JDK
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
>
> When infinispan testsuite(Alpha3) is running with Azul JDK
> java.runtime.version = 1.6.0_33-b5
> java.runtime.name =Java(TM) SE Runtime Environment
> java.vm.version = 1.6.0_33-ZVM_5.5.3.0-b5-product-azlinuxM-X86_64
> java.vm.vendor = Azul Systems, Inc.
> os.name = Linux
> os.version = 2.6.32-358.11.1.el6.x86_64
> sun.arch.data.model = 64
> sun.cpu.endian = little
> Wollowing redundant Exception occurs
> Error Message
> Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor ---- Debugging information ---- message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor class : org.infinispan.container.entries.ImmortalCacheValue required-type : org.infinispan.container.entries.ImmortalCacheValue converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter path : /org.infinispan.container.entries.ImmortalCacheValue line number : 1 version : 1.4.1-redhat-2 -------------------------------
> Stacktrace
> com.thoughtworks.xstream.converters.ConversionException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> ---- Debugging information ----
> message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> cause-exception : com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message : Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> class : org.infinispan.container.entries.ImmortalCacheValue
> required-type : org.infinispan.container.entries.ImmortalCacheValue
> converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
> path : /org.infinispan.container.entries.ImmortalCacheValue
> line number : 1
> version : 1.4.1-redhat-2
> -------------------------------
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:79)
> at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134)
> at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1035)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1019)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:895)
> at com.thoughtworks.xstream.XStream.fromXML(XStream.java:886)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromObjectStream(TestObjectStreamMarshaller.java:65)
> at org.infinispan.marshall.TestObjectStreamMarshaller.objectFromByteBuffer(TestObjectStreamMarshaller.java:97)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectFromInputStream(AbstractMarshaller.java:105)
> at org.infinispan.loaders.jdbc.JdbcUtil.unmarshall(JdbcUtil.java:66)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.readStoredEntry(JdbcStringBasedCacheStore.java:391)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:328)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.loadLockSafe(JdbcStringBasedCacheStore.java:67)
> at org.infinispan.loaders.spi.LockSupportCacheStore.load(LockSupportCacheStore.java:128)
> at org.infinispan.loaders.spi.AbstractCacheLoader.containsKey(AbstractCacheLoader.java:34)
> at org.infinispan.loaders.BaseCacheStoreTest.testCommitAndRollbackWithoutPrepare(BaseCacheStoreTest.java:427)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: com.thoughtworks.xstream.converters.reflection.ObjectAccessException: Cannot construct org.infinispan.container.entries.ImmortalCacheValue as it does not have a no-args constructor
> at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.newInstance(PureJavaReflectionProvider.java:71)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.instantiateNewInstance(AbstractReflectionConverter.java:424)
> at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:229)
> at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)
> ... 40 more
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
> After implementing or extending Serializable interface in BucketInternalCacheEntry, InternalCacheValue exception disappeared
> Second build was done with Alpha4 version and the same exception appers because of new classes and functionality added
> You can see it in jenkins http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-62-ispn-testsuite...
--
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
12 years
[JBoss JIRA] (ISPN-3537) Custom interceptor with Position.LAST set programmatically doesn't work
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3537?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3537:
--------------------------------
Labels: 620 630 (was: 620)
> Custom interceptor with Position.LAST set programmatically doesn't work
> -----------------------------------------------------------------------
>
> Key: ISPN-3537
> URL: https://issues.jboss.org/browse/ISPN-3537
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 6.0.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
>
> When configuring cache programmatically, adding a custom interceptor with position set to Position.LAST cause not calling this interceptor.
> Code sample:
> {code:borderStyle=solid}
> EmbeddedCacheManager manager = new DefaultCacheManager();
> Configuration c2 = new ConfigurationBuilder()
> .customInterceptors()
> .addInterceptor() .position(InterceptorConfiguration.Position.LAST).interceptor(new MyInterceptor())
> .build();
> manager.defineConfiguration("interceptors", c2);
> Cache<String, String> cache = manager.getCache("interceptors");
> cache.put("hello", "world");
> {code}
> MyInterceptor is very simple, reacting to all events. When changing to Position.FIRST, everything works fine. Also tried two/three interceptors, various combinations, but always with same result - when position set to Position.LAST, interceptors is not called.
> Note that no problem when setting by index().
--
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
12 years
[JBoss JIRA] (ISPN-3367) ClusterTopologyManagerTest.testClusterRecoveryWithRebalance fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3367?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3367:
--------------------------------
Labels: 630 testsuite_stability (was: testsuite_stability)
> ClusterTopologyManagerTest.testClusterRecoveryWithRebalance fails randomly
> --------------------------------------------------------------------------
>
> Key: ISPN-3367
> URL: https://issues.jboss.org/browse/ISPN-3367
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Alpha1, 6.0.2.Final
> Environment: {w2k8r2 OracleJDK1.7}, { RHEL6_x86_64, OracleJDK1.7 and OpenJDK1.7}, {solaris10_x86_64 and solaris10-sparc_x86_64, OracleJDK1.7}
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Labels: 630, testsuite_stability
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: ClusterTopologyManagerTest.log.zip
>
>
> Error Message
> Thread already timed out waiting for event merge
> Stacktrace
> java.lang.IllegalStateException: Thread already timed out waiting for event merge
> at org.infinispan.test.fwk.CheckPoint.trigger(CheckPoint.java:131)
> at org.infinispan.test.fwk.CheckPoint.triggerForever(CheckPoint.java:120)
> at org.infinispan.statetransfer.ClusterTopologyManagerTest.testClusterRecoveryWithRebalance(ClusterTopologyManagerTest.java:280)
> 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:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Add links to jenkins jobs
> windows, OracleJDK1.7>>>
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> Linux, OracleJDK1.7>>>
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> Linux, OpenJDK1.7>>>
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
12 years
[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3335:
--------------------------------
Labels: 620 630 (was: 620)
> JMX statistics for Queries partially doesn't work
> -------------------------------------------------
>
> Key: ISPN-3335
> URL: https://issues.jboss.org/browse/ISPN-3335
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Alpha1
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: QueryMBeanTest.java
>
>
> I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query.
> The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected:
> getNumberOfIndexedEntities(String entity)
> clear()
> I've tried also to retrieve the statistics using the following method:
> {code}
> Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime()
> {code}
> and it returns the same results as if getting via JMX.
> You can find the whole running test attached.
> Best regards,
> Anna.
--
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
12 years
[JBoss JIRA] (ISPN-3354) Multiple events on the local node with Infinispan 5.3.0-final
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3354?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3354:
--------------------------------
Labels: 620 630 (was: 620)
> Multiple events on the local node with Infinispan 5.3.0-final
> -------------------------------------------------------------
>
> Key: ISPN-3354
> URL: https://issues.jboss.org/browse/ISPN-3354
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 5.3.0.Final
> Reporter: Luca Zenti
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: TestInfinispanDuplicatedEvents.java
>
>
> After upgrading to Infinispan 5.3.0-final I found a strange "intermittent" problem in my application. Digging a bit deeper, I found out it is due to CacheEntry events raised twice for some keys on the local node (the node where the cache operation is invoked).
> I was able to reproduce the problem and I wrote the attached test case.
> The problem happens regardless of the cluster mode, but only with non-transactional caches. I think this is due to the fact that with transactional caches the events are raised on commit.
> Also, my application used to work with an interceptor rather than an event listener, so I actually found the problem when I saw my interceptor being occasionally executed 3 times with 2 nodes.
> I'm not sure whether the command and the chain of interceptor is really meant to be executed twice on the local node, but the consequent behaviour on the events sounds like a bug.
--
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
12 years
[JBoss JIRA] (ISPN-3364) Tests from org.infinispan.atomic package fail with AssertionError
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3364?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3364:
--------------------------------
Labels: 620 630 (was: 620)
> Tests from org.infinispan.atomic package fail with AssertionError
> -----------------------------------------------------------------
>
> Key: ISPN-3364
> URL: https://issues.jboss.org/browse/ISPN-3364
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.1.Final
> Environment: RHEL5_x86, RHEL5_x86_64, RHEL6_x86, RHEL5_x86_64 with IBM JDK7
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Labels: 620, 630
> Fix For: 6.0.2.Final, 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: LocalDeltaAwarePassivationTest.log.zip, ReplDeltaAwarePassivationTest.log.zip
>
>
> Following tests fail from org.infinispan.atomic package
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap2
> Add link on jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
12 years
[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3316:
--------------------------------
Labels: 620 630 (was: 620)
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI Integration
> Affects Versions: 5.3.0.Final, 6.0.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
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
12 years
[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3048:
--------------------------------
Labels: 620 630 (was: 620)
> Eviction needs to be transactional
> ----------------------------------
>
> Key: ISPN-3048
> URL: https://issues.jboss.org/browse/ISPN-3048
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored.
> We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies.
--
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
12 years