On Thu, Dec 6, 2018 at 10:58 PM Luca Tagliani <[email protected]> wrote: > > Hi Julian, > i'm Raffaele's colleague and perhaps I can better specify the strange > behaviour that we are facing. > > The scenario is the following: > 1) create a new node (NOT versionable) > 2) set some properties > 3) save the session > 4) set a previously not existing property on the node itself > 5) saving the session > > At stage 5) we face a strange behaviour: the Jackrabbit session, using its > SharedItemStateManager (SISM), tries to retrieve from the cache the bundle > for the property (method getItemState at line 258 in trunk), but doesn't > find it in its internal (call to getNonVirtualItemState() throws an > exception), so execution proceed to the for cycle at line 283. > In this for cycle the SISM checks its VirtualItemStateProvider that in fact > contains a VersionItemStateProvider and a VirtualNodeTypeStateProvider. > Obviously, the bundle is not in the version cache, so the persistenceManager > bounded to the VersionItemStateProvider tries to retrieve it from the DB, > thus executing the query "select BUNDLE_DATA from VERSION_BUNDLE where > NODE_ID = :1".
Yes, it was reproducible to me. Thanks for the elaborated steps and investigation! At the step 4, it needs to know whether or not the new property already exists--whether or not it needs to create a new property. So, it needs to retrieve the node state. And, as you pointed out, the VirtualItemStateProvider, one of the SharedItemStateManager#virtualProviders, is asked if it has that node item by ItemId. > > To me this is not correct in two ways: > a) I think that, after the save in stage 3 the bundle should be in cache It seems debatable to me. The current design seems to have assumed that an item should be cached only on retrieval, which makes sense to me. It's simpler and batch additions don't need to cache, for example. > b) even if the bundle is not in cache, it doesn't have to be retrieved from > the versioning layer if the corresponding nodeType is not versionable If a non-versionable node is a child of a versionable node, then it should be retrieved from the Versioning's PersistenceManager. So, it seems more complex than that. In addition, the current API such as o.a.j.core.state.ItemStateManager#getItemState(ItemId) doesn't give any information about node type and node hierarchy. Therefore, I assume it is really difficult to fix that in the core level considering (a) o.a.j.core.state.ItemStateManager is widely used from many different packages, and (b) Jackrabbit 2 is in the maintenance mode. > > If this is right, we should consider a patch to avoid the problem putting > the bundle in cache after a save or avoid the search in versions. > > I'd like to have from you some advice on my thoughts, first if they seems > correct to you or I am misunderstand the behaviour. Another approach is to override the VersionItemStateProvider in your application. Basically a repository implementation such as o.a.j.core.RepositoryImpl registers those two VirtualItemStateProviders through SharedItemStateManager#addVirtualItemStateProvider(VirtualItemStateProvider). If you can override this behavior through a more optimized VersionItemStateProvider somehow--possibly including some dirty code to access node types or node hierarchy--you can possibly achieve the goal. You might also want to suggest some simple refactoring in RepositoryImpl for example to make the overriding easier, which seems less risky to everyone. Just my two cents, Woonsan > > Thanks in advance > > BR > > Luca Tagliani > > > > -- > Sent from: > http://jackrabbit.510166.n4.nabble.com/Jackrabbit-Users-f510167.html
