Hi, we hit a similar problem a while ago with session logout: https://issues.apache.org/jira/browse/JCR-2231
might be worth creating a JIRA issue for your case. regards marcel > -----Original Message----- > From: Sergiy Shyrkov [mailto:[email protected]] > Sent: Mittwoch, 3. April 2013 23:52 > To: [email protected] > Subject: CachingHierarchyManager.stateDiscarded() call to > provider.hasItemState(discarded.getId()) > > Hello guys, > > I would need your help in understanding the code in the > CachingHierarchyManager.stateDiscarded() method (Jackrabbit 2.2.4). > A short background: > I am working on a tool to purge orphaned version history from the > repository (version history for nodes, which are no longer present in > the repository). > The version store is quite large (the row count in the version bundle > table is around 12 000 000 entries). > When profiling the tool execution I see in the snapshot that in the > CachingHierarchyManager.stateDiscarded() method the > provider.hasItemState(discarded.getId()) is called. > In my case this happens quite often and the call provider.hasItemState() > goes into the DB and loads the bundle. > The things is that the item is no longer present and the > provider.hasItemState() evaluates to false. > > The call in my case is coming from the > org.apache.jackrabbit.core.state.ChangeLog.persisted() where we have the > following lines: > > ... > for (ItemState state : deletedStates()) { > state.setStatus(ItemState.STATUS_EXISTING_REMOVED); > state.notifyStateDestroyed(); > state.discard(); > } > ... > > The state.discard() calls the notifyStateDiscarded(); > > Is it really needed here after we have already called > state.notifyStateDestroyed()? > > If yes, is there any way we can optimize the check in the > CachingHierarchyManager.stateDiscarded() to not call > provider.hasItemState() in some cases? Perhaps check for > discarded.getStatus() != ItemState.STATUS_EXISTING_REMOVED first or > similar? > > I am attaching the profiler snapshot > (CachingHierarchyManager-stateDiscarded.png) and just in case the image > won't get through the mailing list, here is a text representation of the > method call trace: > > org.apache.jackrabbit.core.state.ChangeLog.persisted() > - org.apache.jackrabbit.core.state.ItemState.discard() > - org.apache.jackrabbit.core.state.ItemState.notifyStateDiscarded() > - > org.apache.jackrabbit.core.state.SharedItemStateManager.stateDiscarded(It > emState) > - > org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarde > d(ItemState) > - > org.apache.jackrabbit.core.state.SharedItemStateManager.stateDiscarded(It > emState) > - > org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarde > d(ItemState) > - > org.apache.jackrabbit.core.CachingHierarchyManager.stateDiscarded(ItemSt > ate) > - > org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(Ite > mId) > - > org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualIte > mState(ItemId) > - > org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceM > anager.exists(PropertyId) > - > org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceM > anager.getBundle(NodeId) > - > org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.l > oadBundle(NodeId) > - > org.apache.jackrabbit.core.util.db.ConnectionHelper.exec(String, > Object[], boolean, int) > > > Thank you in advance for any hints! > Sergiy Shyrkov
