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". 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 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 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. Thanks in advance BR Luca Tagliani -- Sent from: http://jackrabbit.510166.n4.nabble.com/Jackrabbit-Users-f510167.html
