On Fri, Jan 27, 2012 at 10:35 AM, Berry van Halderen <[email protected]> wrote: > On Tue, Dec 6, 2011 at 4:40 PM, Berry van Halderen > <[email protected]> wrote: >> We've run into log messages that have come us to suspect one of our >> practices, namely to reregister node types. The reregistering occurs >> in a clustered environment, where other clustered nodes keep on using >> the node types, but on rare occasion certain exceptions are thrown, >> most particular an exception from getEffetiveNodeType when retrieving >> a node from the persistent store. I've still to evaluate if it is >> indeed the case, but we're wondering if it is at all safe to do >> changing node type operations in a clustered environment. >> Note, before 2.2.x we did not see these kind of errors, currently on >> 2.2.9 we are. > > I was able myself to track it down. It turns out that before > re-registering there > was also a call to unregister a node type. That caused a small gap > between the unregister and the re-register where other cluster nodes could > have received the unregister but not the new type. > > I've fixed this in our own code, but still I'm a bit worried about this change > of behavior It used to be impossible to unregister a node type when it > was still in use (or at least never to unregister a node type). Not being > able to unregister a node type when still in use seems to be the most > correct semantics.
agreed, but unortunately also the most expensive/difficult to implement... AFAIK it's currently not possible to unregister a node type through the public api (javax.jcr.NodeTypeManager#unregisterNodeType) the key here is the following method: NodeTypeRegistry.checkForReferencesInContent() this method currently throws unconditionally. the javadoc explains why. > > But what actually happened in Jackrabbit was actually quite scary. > By being able to unregister a node type in use, other nodes load and > modify a node with a mixin type that is being unregistered. The > mixin type is silently dropped from the node, but any properties tied > to the mixin node type are kept. There is a window where such a > node can be persisted back into database. > > What is then left in the persisted storage is a node with properties > that cannot be part of that node according to its node type. And > this node cannot be loaded, cannot be deleted, cannot be fixed. > The only option is to go into sql level to delete the node or fix the > binary bundle data stored in the record. > > Maybe it's a good idea that we're not able to remove node types that > are still in use, wdyt? theoretically, yes. the hard part is to determine whether it's actually in use... cheers stefan > > \Berry
