CacheLoader preload with region based marshalling
by Brian Stansberry
Not sure if this is a bug or not or just misconfiguration that the
JBCACHE-1358 fix exposed.
The cache used for JBAS FIELD granularity web sessions uses region based
marshalling and has a CacheLoader with <preload>/</preload>. Starting
the cache with anything in the persistent store results in failure.
This looks to be the cause of tons of regressions when trying to use
2.2.0.CR2 in AS 5.
The failure:
2008-06-03 21:21:35,363 INFO [org.jboss.cache.RPCManagerImpl] (RMI TCP
Connection(94)-127.0.0.1) Cache local address is 127.0.0.1:35029
2008-06-03 21:21:35,363 DEBUG
[org.jboss.cache.loader.CacheLoaderManager] (RMI TCP
Connection(94)-127.0.0.1) preloading transient state from cache loader
org.jboss.cache.loader.FileCacheLoader@18543c
2008-06-03 21:21:35,365 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,366 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,367 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,368 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,368 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,369 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,369 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,370 DEBUG
[org.jboss.cache.interceptors.ActivationInterceptor] (RMI TCP
Connection(94)-127.0.0.1) no children UnversionedNode[
/JSESSION/localhost/http-scoped-field/__JBossInternal__/lzRERFRa-nr46LmuwOxjeQ__/ATTRIBUTE/TEST_ID/_ID_/5c4o141-11g0p5-fh19wt1g-1-fh1amjdr-tl
data=[__SERIALIZED__, POJOCache.Status, POJOCache.PojoInstance, ]]
2008-06-03 21:21:35,370 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,371 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,371 DEBUG
[org.jboss.cache.marshall.CacheMarshaller210] (RMI TCP
Connection(94)-127.0.0.1) Region does not exist for Fqn null - not using
a context classloader.
2008-06-03 21:21:35,374 ERROR
[org.jboss.web.tomcat.service.deployers.TomcatDeployment] (RMI TCP
Connection(94)-127.0.0.1) Failed to setup clustering, clustering
disabled. Exception:
org.jboss.cache.CacheException: Unable to invoke method public void
org.jboss.cache.loader.CacheLoaderManager.preloadCache() throws
org.jboss.cache.CacheException on object instance
org.jboss.cache.loader.CacheLoaderManager@1427899
at
org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:127)
at
org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:935)
at
org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:721)
at
org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:585)
at
org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:268)
at
org.jboss.web.tomcat.service.session.JBossCacheManager.initCacheProxy(JBossCacheManager.java:277)
at
org.jboss.web.tomcat.service.session.JBossCacheManager.init(JBossCacheManager.java:244)
at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:375)
at
org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:139)
at
org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:431)
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:112)
at org.jboss.web.deployers.WebModule.start(WebModule.java:90)
at sun.reflect.GeneratedMethodAccessor426.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at
org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
at $Proxy35.start(Unknown Source)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at
org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:271)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1394)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:786)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:914)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:836)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:674)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:456)
at org.jboss.system.ServiceController.doChange(ServiceController.java:664)
at org.jboss.system.ServiceController.start(ServiceController.java:436)
at
org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:150)
at
org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:108)
at
org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at
org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:991)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1394)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:786)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:914)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:836)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:674)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:456)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:812)
at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:587)
at sun.reflect.GeneratedMethodAccessor311.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at sun.reflect.GeneratedMethodAccessor240.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:270)
at sun.reflect.GeneratedMethodAccessor237.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at
org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at
org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
at
org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at
org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
at sun.reflect.GeneratedMethodAccessor236.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at
org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:815)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:416)
at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor409.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:123)
... 101 more
Caused by: org.jboss.cache.CacheException:
java.lang.ClassNotFoundException:
org.jboss.test.cluster.web.DeserializationSensor
at
org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:227)
at
org.jboss.cache.invocation.CacheInvocationDelegate.get(CacheInvocationDelegate.java:360)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:337)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preload(CacheLoaderManager.java:368)
at
org.jboss.cache.loader.CacheLoaderManager.preloadCache(CacheLoaderManager.java:310)
... 105 more
Caused by: java.lang.ClassNotFoundException:
org.jboss.test.cluster.web.DeserializationSensor
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at
org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:207)
at
org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1009)
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:728)
at
org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at
org.jboss.util.stream.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:62)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:540)
at
org.jboss.cache.marshall.CacheMarshaller200.populateFromStream(CacheMarshaller200.java:750)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallHashMap(CacheMarshaller200.java:713)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:571)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:513)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStreamRegionBased(CacheMarshaller200.java:202)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:126)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromObjectStream(VersionAwareMarshaller.java:326)
at
org.jboss.cache.loader.FileCacheLoader.doUnmarshall(FileCacheLoader.java:481)
at
org.jboss.cache.loader.AbstractCacheLoader.regionAwareUnmarshall(AbstractCacheLoader.java:223)
at
org.jboss.cache.loader.FileCacheLoader.loadAttributes(FileCacheLoader.java:434)
at org.jboss.cache.loader.FileCacheLoader.get(FileCacheLoader.java:201)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.loadData(CacheLoaderInterceptor.java:554)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.loadNode(CacheLoaderInterceptor.java:481)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:305)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:136)
at
org.jboss.cache.interceptors.ActivationInterceptor.visitGetKeyValueCommand(ActivationInterceptor.java:117)
at
org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:72)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.handleGetKeyValueCommand(PessimisticLockInterceptor.java:310)
at
org.jboss.cache.interceptors.base.PostProcessingCommandInterceptor.visitGetKeyValueCommand(PostProcessingCommandInterceptor.java:228)
at
org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:72)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
at
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:157)
at
org.jboss.cache.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:80)
at
org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:72)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
at
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:157)
at
org.jboss.cache.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:80)
at
org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:72)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
at
org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:266)
at
org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:253)
at
org.jboss.cache.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:80)
at
org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:72)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:75)
at
org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:72)
at
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:142)
at
org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:158)
at
org.jboss.cache.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:108)
at
org.jboss.cache.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:80)
at
org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:72)
at
org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:215)
... 117 more
http://jira.jboss.com/jira/browse/JBCACHE-1009 is a conceptually related
JIRA.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
17 years, 9 months
POJO Cache 2.2.0.CR5 released
by Jason T. Greene
Ok, finally got it out. So it's ready for testing. Now to return to my
vacationing ;)
--
Jason T. Greene
JBoss, a division of Red Hat
18 years
Temporarily forked JBossCacheView demo
by Jason T. Greene
I discovered another API incompatibility introduced by the recent
refactor, so to work around the problem, without forcing another core
cache release, I have forked it under the pojo demo package. This is a
short term solution.
--
Jason T. Greene
JBoss, a division of Red Hat
18 years
POJO Cache no longer uses self-weaved interceptor stack
by Jason T. Greene
I just finished PCACHE-68, which removes the AOP weaved interceptor
stack. This eliminates the possibility of a binary compatibility issue
due to an AOP version change. This also means that aopc is no longer
part of the POJO Cache build. It also simplifies the code a bit since
the interceptor design was overkill.
--
Jason T. Greene
JBoss, a division of Red Hat
18 years
ReversibleCommands and locking schemes
by Manik Surtani
A sub-interface of Command is ReversibleCommand, which exposes a
rollback() method. The purpose of this method is that for commands
that change the state of the cache, the command also maintains
information on how to undo it's change, and the undo operation is
invoked by calling rollback() on the command. A nice, clean way of
encapsulating a change and it's reversal.
Now this only made sense for pessimistic locking, where changes are
made directly on the cache. With optimistic locking, changes are made
in a workspace and a rollback is performed by simply throwing away the
workspace. MVCC is similar in this regard, where changes are made to
a copy of the node, and a rollback is performed by throwing away this
new node.
So, is rollback() (and the ReversibleCommand interface) tied to
pessimistic locking only? And if so, that is a lot of overhead each
command stores for the sake of a single locking scheme (especially
when those commands are used with Optimistic Locking or MVCC). Should
we introduce another set of commands, subclasses to the actual
commands themselves, implementing rollback, such that they are used
for pessimistic locking, while leaner commands without rollback can be
used for the other locking schemes? Or should we just "live with"
this overhead until MVCC stabilises and we deprecate/remove
pessimistic and optimistic locking altogether?
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years
POJO tunk now builds for everyone besides me
by Jason T. Greene
The latest AOP snapshot allows for the maven build to work without a
local override. Also, Kabir is going to be doing an AOP CR release in
the next couple of days that includes my javassist work, so as soon as
that as done we can release a POJO 2.2 CR.
--
Jason T. Greene
JBoss, a division of Red Hat
18 years
Re: [jbosscache-dev] ReversibleCommands and locking schemes
by Manik Surtani
I agree re: separating the PL logic from the commands since it is
specific to the locking scheme.
Re: OL, so far there is no OL specific logic in the commands - it all
exists in the OL interceptors. Agreed that it would be cleaner to
have a separate set of commands to hold this logic, but given that we
don't plan to support OL in the long term, I'd rather not spend the
time and effort on this.
The only reason it makes sense for PL is that it makes the commands
leaner and lighter for MVCC and removes irrelevant code.
On 27 Jun 2008, at 15:21, Mircea Markus wrote:
> I also vote for separate logic.
> What about creating a set of commands to hold appropriate logic for
> optimistic licking as well - (this would contain logic moved from
> some of the Optimistic interceptors).
> I think the code would be more readable this way, the commands would
> be unit testable, and we would be able to optimize it it better.
>
> Brian Stansberry wrote:
>> I'd say separate it out. You might have to live with PL for a long
>> time, and refactoring it later when 3.x is stable/people depend on
>> it is more problematic. Seems like now (or before the first
>> 3.0.0.CR) is a better time to do this kind of stuff.
>>
>> Manik Surtani wrote:
>>> A sub-interface of Command is ReversibleCommand, which exposes a
>>> rollback() method. The purpose of this method is that for
>>> commands that change the state of the cache, the command also
>>> maintains information on how to undo it's change, and the undo
>>> operation is invoked by calling rollback() on the command. A
>>> nice, clean way of encapsulating a change and it's reversal.
>>>
>>> Now this only made sense for pessimistic locking, where changes
>>> are made directly on the cache. With optimistic locking, changes
>>> are made in a workspace and a rollback is performed by simply
>>> throwing away the workspace. MVCC is similar in this regard,
>>> where changes are made to a copy of the node, and a rollback is
>>> performed by throwing away this new node.
>>>
>>> So, is rollback() (and the ReversibleCommand interface) tied to
>>> pessimistic locking only? And if so, that is a lot of overhead
>>> each command stores for the sake of a single locking scheme
>>> (especially when those commands are used with Optimistic Locking
>>> or MVCC). Should we introduce another set of commands, subclasses
>>> to the actual commands themselves, implementing rollback, such
>>> that they are used for pessimistic locking, while leaner commands
>>> without rollback can be used for the other locking schemes? Or
>>> should we just "live with" this overhead until MVCC stabilises and
>>> we deprecate/remove pessimistic and optimistic locking altogether?
>>>
>>> Thoughts?
>>> --
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> manik(a)jboss.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years
Documentation updates
by Manik Surtani
Guys,
If you need to make changes to the docs in trunk, please let me know
before you do these. The docs team have refactored the dir structure
here to deal with translations, and I will have to apply these changes
to trunk before any other changes are made to the contents.
I hope to do this next week, but if you want to bump up prio on this
if you're waiting to check in doc updates, then let me know.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years
Re: [hibernate-dev] JBoss Cache Searchable interfaces
by Manik Surtani
On 26 Jun 2008, at 13:48, Emmanuel Bernard wrote:
<SNIP />
>> * iterator();
> don't think it's that useful in practice, scroll is probably more
> practical as it lazily loads Lucene data (contrary to iterator)
Then why don't we just lazily load Lucene data into the iterator and
drop scroll()? I see supporting both as superfluous. And iterator()
is more familiar to devs.
> That's the point of Scroll, but you can rename it if you want.
> What's important is that you need a .close() method to release the
> lucene resources. also scroll() could return null if the object is
> not found in the cache (inconsistency), iterate() will just ignore
> the entry.
+1, good point. We'd need a close() method on the QueryResultIterator.
I see just returning a null if the object is not in the cache as
something people would expect.
>> I think that any benefit of a scrollable result set window
>> preventing loading unnecessary objects from a DB are lost when your
>> backing store is a cache and the objects are in memory anyway. And
>> besides, any further optimisations can be in the iterator
>> implementation, such as just maintaining a list of CachedEntityIds
>> (a composite of Fqn and key) and fetching the objects from the
>> cache lazily, as required.
>
> iterate() lazily load object from the DB but eagerly loads Lucene
> stuffs
> scroll() lazily load everything but need a .close()
If you think eager loading of Lucene data is something people would
find useful, we could have 2 separate implementations of the
QueryResultIterator - a QRILazyImpl and a QRIEagerImpl. And the
interface to obtain these could be on the CacheQuery interface:
CacheQuery.iterator(boolean lazy);
> You can use your own Scrolalble interface, that's fair. Essentially
> Search should look natural to cache users, not Hibernate users :)
Yup. :-)
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years
Cloneable
by Manik Surtani
I'm trying to move away from using Cloneable, it is generally
considered to be a broken API [1]. So I have removed Cloneable from
all *internal* classes where they existed (Fqn, InvocationContext,
Region, some Commands) but they also exist on public API classes (such
as all Configuration elements, Option) so we have to live with it
there. But we should keep it to a minimum and make sure we don't use
this in future classes.
Cheers
Manik
[1] http://www.artima.com/intv/bloch13.html
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years
