[JBoss JIRA] (ISPN-3685) HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3685?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3685:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1026862
> HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3685
> URL: https://issues.jboss.org/browse/ISPN-3685
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.CR1
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> During process of HotRod Rolling Upgrades from cluster of 2 JDG 6.1.GA nodes to 2 JDG 6.2.ER3.2 nodes, we are blocked by this exception while calling recordKnownGlobalKeyset operation on "old" cluster:
> java.io.IOException: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1775)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$MessageReceiver$1.run(ClientConnection.java:455)
> 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)
> Caused by: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:72)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1766)
> ... 4 more
> This is also the same for Infinispan Server build from upstream, so it shouldn't be product specific.
--
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, 5 months
[JBoss JIRA] (ISPN-3685) HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-3685:
----------------------------------
Summary: HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
Key: ISPN-3685
URL: https://issues.jboss.org/browse/ISPN-3685
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 6.0.0.CR1
Reporter: Tomas Sykora
Assignee: Mircea Markus
Fix For: 6.0.0.Final
During process of HotRod Rolling Upgrades from cluster of 2 JDG 6.1.GA nodes to 2 JDG 6.2.ER3.2 nodes, we are blocked by this exception while calling recordKnownGlobalKeyset operation on "old" cluster:
java.io.IOException: java.lang.ClassNotFoundException: org.infinispan.CacheException
at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1775)
at org.jboss.remotingjmx.protocol.v1.ClientConnection$MessageReceiver$1.run(ClientConnection.java:455)
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)
Caused by: java.lang.ClassNotFoundException: org.infinispan.CacheException
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:72)
at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1766)
... 4 more
This is also the same for Infinispan Server build from upstream, so it shouldn't be product specific.
--
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, 5 months
[JBoss JIRA] (ISPN-3685) HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
by Tomas Sykora (JIRA)
[ https://issues.jboss.org/browse/ISPN-3685?page=com.atlassian.jira.plugin.... ]
Tomas Sykora updated ISPN-3685:
-------------------------------
Fix Version/s: 6.0.0.CR2
> HotRod Rolling Upgrades ClassNotFoundException: org.infinispan.CacheException during recordKnownGlobalKeyset
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3685
> URL: https://issues.jboss.org/browse/ISPN-3685
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.0.CR1
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> During process of HotRod Rolling Upgrades from cluster of 2 JDG 6.1.GA nodes to 2 JDG 6.2.ER3.2 nodes, we are blocked by this exception while calling recordKnownGlobalKeyset operation on "old" cluster:
> java.io.IOException: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1775)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$MessageReceiver$1.run(ClientConnection.java:455)
> 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)
> Caused by: java.lang.ClassNotFoundException: org.infinispan.CacheException
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:947)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1259)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1732)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1648)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1290)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:72)
> at org.jboss.remotingjmx.protocol.v1.ClientConnection$BaseResponseHandler.handle(ClientConnection.java:1766)
> ... 4 more
> This is also the same for Infinispan Server build from upstream, so it shouldn't be product specific.
--
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, 5 months
[JBoss JIRA] (ISPN-3684) Improve L1 consitency with backup owners
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3684?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-3684:
-----------------------------------
Assignee: William Burns (was: Mircea Markus)
> Improve L1 consitency with backup owners
> ----------------------------------------
>
> Key: ISPN-3684
> URL: https://issues.jboss.org/browse/ISPN-3684
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Final
>
>
> ISPN-3648 fixed an issue that can occur when a backup owner replies with an outdated value.
> More details on the original issue can be found at ISPN-3426.
> This JIRA is to improve this fix to be something more desirable.
> There are a few ways that this could be done.
> # Change it so that remote gets only go to the primary owner, which guarantees consistency with that owner (this still has issues with fail over when that primary owner goes down)
> # Change it so that values are only added to L1 if the value was retrieved from the primary owner. (note there is still some stuff to think about for fail over here)
> # Multicast the invalidation message from the primary owner after updating the value. This is the simplest approach (no requestors map required), but may also have some performance concerns.
--
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, 5 months
[JBoss JIRA] (ISPN-3684) Improve L1 consitency with backup owners
by William Burns (JIRA)
William Burns created ISPN-3684:
-----------------------------------
Summary: Improve L1 consitency with backup owners
Key: ISPN-3684
URL: https://issues.jboss.org/browse/ISPN-3684
Project: Infinispan
Issue Type: Enhancement
Components: Distributed Cache
Affects Versions: 6.0.0.CR1
Reporter: William Burns
Assignee: Mircea Markus
Fix For: 7.0.0.Final
ISPN-3648 fixed an issue that can occur when a backup owner replies with an outdated value.
More details on the original issue can be found at ISPN-3426.
This JIRA is to improve this fix to be something more desirable.
There are a few ways that this could be done.
# Change it so that remote gets only go to the primary owner, which guarantees consistency with that owner (this still has issues with fail over when that primary owner goes down)
# Change it so that values are only added to L1 if the value was retrieved from the primary owner. (note there is still some stuff to think about for fail over here)
# Multicast the invalidation message from the primary owner after updating the value. This is the simplest approach (no requestors map required), but may also have some performance concerns.
--
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, 5 months
[JBoss JIRA] (ISPN-3552) HotRod Rolling Upgrades NPE when disabling cache store on target node
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3552?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3552:
-----------------------------------------------
Tomas Sykora <tsykora(a)redhat.com> made a comment on [bug 1011499|https://bugzilla.redhat.com/show_bug.cgi?id=1011499]
This issue depends on: https://bugzilla.redhat.com/show_bug.cgi?id=1026862
Formerly, I thought 1026862 exception is related to disabling remote cache store. This is not true and this issue blocks even the first of rolling upgrades operations -- recordKnownGlobalKeyset.
Once https://bugzilla.redhat.com/show_bug.cgi?id=1026862 is fixed and verified, this issue can be consequently verified as well.
We should remove this (1011499) bugzilla from beta release notes as it is superseded by 1026862 for now.
> HotRod Rolling Upgrades NPE when disabling cache store on target node
> ---------------------------------------------------------------------
>
> Key: ISPN-3552
> URL: https://issues.jboss.org/browse/ISPN-3552
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Beta1
> Reporter: Tomas Sykora
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.CR2
>
> Attachments: standalone-source-node-rollups52-dist.xml, standalone-target-node-rollups-dist.xml
>
>
> After Tristan's fix for https://issues.jboss.org/browse/ISPN-3183 we can move successfully through recordKnownGlobalKeyset and synchronizeData operations.
> However, when we want to issue disconnectSource operation on target node, it is failing with given error:
> javax.management.MBeanException
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:273)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1058)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:225)
> 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)
> Caused by: java.lang.reflect.InvocationTargetException
> 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.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271)
> ... 9 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.manager.PersistenceManagerImpl.disableStore(PersistenceManagerImpl.java:253)
> at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.disconnectSource(HotRodTargetMigrator.java:101)
> at org.infinispan.upgrade.RollingUpgradeManager.disconnectSource(RollingUpgradeManager.java:71)
> ... 14 more
> Short input from Tristan: "problem is that after removing the store, it determines there are no more stores left so it tries to remove the loader/writer interceptors which for some reason are missing"
>
--
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, 5 months
[JBoss JIRA] (ISPN-3518) 1PC can cause a window of inconsistency with L1 invalidation
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3518?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3518 started by William Burns.
> 1PC can cause a window of inconsistency with L1 invalidation
> ------------------------------------------------------------
>
> Key: ISPN-3518
> URL: https://issues.jboss.org/browse/ISPN-3518
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.3.0.Final
> Reporter: William Burns
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes.
> Example:
> {quote}
> Node A owns k with value of v1
> Node B has k in L1 with value of v1
> tx1 started
> Node A put k -> v2
> Node A sends invalidation
> Node A commits
> tx1 completed
> tx2 started
> Node B get k returns v1 from L1
> tx2 completed
> Node B gets invalidation for k
> tx3 started
> Node B get k remotely retrieves v2 from Node A
> tx3 completed
> {quote}
> We need to make sure that all L1 invalidations in Tx mode are completed before completing the transaction.
--
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, 5 months
[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:
--------------------------------
Fix Version/s: 6.0.0.Final
> 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
> Fix For: 6.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, 5 months
[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:
--------------------------------
Fix Version/s: 6.0.0.Final
> 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
> Fix For: 6.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, 5 months