Fix for JBCACHE-1555
by Galder Zamarreno
Hi,
Re: https://jira.jboss.org/jira/browse/JBCACHE-1555
I've got a fix for this issue that fixes both the writeSkew=true and
writeSkew=false situations:
The problem as stated in 1555 is that
MVCCNodeHelper.wrapNodeForWriting() peeks for data, via
DC.peekInternalNodeAndDirectParent before acquiring any locks. So, if a
thread ends up waiting for the lock and someone else comes and writes
the data, when the waiting thread wakes up, it uses stale peeked data.
The solution I propose is the following:
if (lockForWriting && acquireLock(context, fqn)) {
needToCopy = true;
// re-peek in case we waited for a lock and some other thread
modified the data while we're waiting
nodes = dataContainer.peekInternalNodeAndDirectParent(fqn,
includeInvalidNodes);
}
n = nodeFactory.createWrappedNode(nodes[0], nodes[1]);
We only need to worry about the case where we wanna write cos on reads,
we never have to acquire locks. So, on writes, after acquiring the lock,
we re-peek to get the most up to date data, which we then use to create
the wrapped node.
This seems to work fine for the test. We'd have to check hudson.
One doubt I have is whether the 1st peak here could be optimised to be
an exist() call:
InternalNode[] nodes =
dataContainer.peekInternalNodeAndDirectParent(fqn, includeInvalidNodes);
InternalNode in = nodes[0];
if (in != null) {
...
However, includeInvalidNodes might be key here and I don't see any
exists in the DataContainer API that allows to pass that parameter. So,
I think this needs to stay as a peek.
Thoughts?
14 years, 10 months
Solution for failing Isolated query cache tests in Hibernate trunk
by Galder Zamarreno
Hi all,
In Hibernate trunk, the following tests are failing:
In JBC 2LC provider:
MVCCIsolatedClassLoaderTest.testClassLoaderHandlingNamedQueryRegion
MVCCIsolatedClassLoaderTest.testClassLoaderHandlingStandardQueryCache
In Infinispan 2LC provider:
IsolatedClassLoaderTest.testClassLoaderHandlingNamedQueryRegion
IsolatedClassLoaderTest.testClassLoaderHandlingStandardQueryCache
They're failing because AccountHolder is being loaded with the system
classloader rather than the SelectedClassnameClassLoader.
The reason for this is that as a result of
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2990,
SerializationHelper.CustomObjectInputStream now takes the classloader in
the constructor. And during the test, SerializableType.fromBytes passes
null as classloader to this constructor. The null comes from
getReturnedClass().getClassLoader() below, which has been added as a
result of 2990.
private Object fromBytes(byte[] bytes) throws SerializationException {
return SerializationHelper.deserialize( bytes,
getReturnedClass().getClassLoader() );
}
Now, shouldn't we use Thread.currentThread().getContextClassLoader()
instead of getReturnedClass().getClassLoader()? Previously, that's what
would have happened. I dunno why getReturnedClass().getClassLoader() was
added though.
I've just tested using Thread.currentThread().getContextClassLoader()
change and the tests pass now. Steve?
Cheers,
14 years, 10 months
implement Serializable in POJOCache
by Kavitha Durai
As per POJOCache specification any non serializable object can be
serialized but when I use Person Class without implementing
Serializable it throws following error.
If I implements Serializableit works well , So IN POJO Cache does class
need to implement Serializable.?
Exception in thread "main" org.jboss.cache.pojo.PojoCacheException:
Failed starting org.jboss.cache.CacheException:
java.lang.reflect.InvocationTargetException
at
org.jboss.cache.pojo.impl.PojoCacheImpl.start(PojoCacheImpl.java:316)
at
org.jboss.cache.pojo.passivation.TRGLocalTest.setUp(TRGLocalTest.java:56
)
at
org.jboss.cache.pojo.passivation.TRGLocalTest.main(TRGLocalTest.java:132
)
Caused by: org.jboss.cache.CacheException:
java.lang.reflect.InvocationTargetException
at
org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionU
til.java:148)
at
org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(Com
ponentRegistry.java:970)
at
org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegis
try.java:746)
at
org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java
:610)
at
org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocation
Delegate.java:355)
at
org.jboss.cache.pojo.impl.PojoCacheImpl.start(PojoCacheImpl.java:312)
... 2 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionU
til.java:144)
... 7 more
Caused by: org.jboss.cache.CacheException:
java.io.InvalidClassException: org.jboss.cache.pojo.test.Person;
org.jboss.cache.pojo.test.Person; class invalid for deserialization
at
org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.ja
va:277)
at
org.jboss.cache.invocation.CacheInvocationDelegate.get(CacheInvocationDe
legate.java:448)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.jav
a:352)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.jav
a:383)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.jav
a:383)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.jav
a:383)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.jav
a:383)
at
org.jboss.cache.loader.CacheLoaderManager.preloadCache(CacheLoaderManage
r.java:325)
... 12 more
Caused by: java.io.InvalidClassException:
org.jboss.cache.pojo.test.Person; org.jboss.cache.pojo.test.Person;
class invalid for deserialization
at
java.io.ObjectStreamClass.checkDeserialize(ObjectStreamClass.java:713)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1733
)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarsha
ller200.java:582)
at
org.jboss.cache.marshall.CacheMarshaller200.populateFromStream(CacheMars
haller200.java:800)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallHashMap(CacheMarsh
aller200.java:763)
Regards,
Kavitha Durai,
This e-mail communication and any attachments may contain confidential and privileged information and are for use by the intended addressee(s) only. If you are not the intended addressee, you have received this communication in error. Any dissemination or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you suspect you have received this communication in error, please notify us immediately by replying to this message and delete it from your computer.Thank you.
14 years, 10 months
Node removed from file system when activated
by Kavitha Durai
I am using FileCacheLoader as a cacheloader and node gets passivated as
expected, But noticed that node is removed from the file system when it
is activated.
How to avoid this behavior of removing the node when it is activated?.
I want the data to be in the file system ever so that it can get
activated whenever it is required.
Regards,
Kavitha Durai.
This e-mail communication and any attachments may contain confidential and privileged information and are for use by the intended addressee(s) only. If you are not the intended addressee, you have received this communication in error. Any dissemination or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you suspect you have received this communication in error, please notify us immediately by replying to this message and delete it from your computer.Thank you.
14 years, 10 months
JBCACHE-1561 - how to get children or children names directly?
by Galder Zamarreno
Hi,
Re: https://jira.jboss.org/jira/browse/JBCACHE-1561
Is there a way in JBC 3.x to get the children or children names without
accessing the cache loader? peek() does not help here and
Option.suppressPersistence only works at the CacheStoreInterceptor level.
Clearly, implementing getChildrenDirect() is not the right thing to do
since this is old PL/OL API. I'd lean towards either extending
Option.suppressPersistence so that it also covers CacheLoaderInterceptor
so that it doesn't get stuff from CL if that option is set to true.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 10 months