Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <3346588.1164792508395.JavaMail.jira@brutus>
Date: Wed, 29 Nov 2006 01:28:28 -0800 (PST)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-617) CachingHieraarchyManager may serve moved
 items
In-Reply-To: <22092028.1162546216606.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/JCR-617?page=all ]

Jukka Zitting updated JCR-617:
------------------------------

    Affects Version/s: 1.1.1

> CachingHieraarchyManager may serve moved items
> ----------------------------------------------
>
>                 Key: JCR-617
>                 URL: http://issues.apache.org/jira/browse/JCR-617
>             Project: Jackrabbit
>          Issue Type: Bug
>    Affects Versions: 1.1, 1.1.1
>            Reporter: Tobias Bocanegra
>         Assigned To: Tobias Bocanegra
>             Fix For: 1.2
>
>
> There is a problem with weak referenced item states and event notification in the
> LocalItemStateManager.
> consider the following:
> - Session A traverses some nodes and fills-up the cache of the ChachingHierarchyManager
> - This also fills the weak-ref cache in Session A LocalItemStateManager.
> - Session B does some operations
> - At some point, GC decides to remove the weakly refferenced ItemStates in Session As
>   LocalItemStateManager
> - Session B moves a node and saves the changes.
> - The SharedItemStateManager notifies all listeners that a node was modified
> - The LocalItemStateManager of Session A receives the event, but does not bubble it,
>   because it does not have the item anymore in its cache
> - The CachingHierarchyManager of Session A never receives the modification event and still
>   servers the items at the old location.
> Solution A:
> reconnect missing states in the LocalItemStateManager when an event is received. this has
> the drawback that a lot of state would be generated that are not needed.
> Solution B:
> add a new event 'nodeModified' that is only sent by the LocalItemStateManager if a
> 'stateModified' was received for which it does not have the item aymore. this has the
> drawback that alot more events are generated.
> Will implement solution B

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira