Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of lists@nabble.com designates
 72.21.53.35 as permitted sender)
Message-ID: <7128759.post@talk.nabble.com>
Date: Wed, 1 Nov 2006 23:10:46 -0800 (PST)
From: Joshua Levy <levy@csl.sri.com>
To: users@jackrabbit.apache.org
Subject: Re: ItemManager warning
In-Reply-To: <90a8d1c00611010850w3e159aa0se276107fd2014cfb@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <7080795.post@talk.nabble.com>
 <90a8d1c00611010850w3e159aa0se276107fd2014cfb@mail.gmail.com>


Hi Stefan,


Stefan Guggisberg wrote:
> 
>> Is this logged at warning level for a reason, and worth
>> worrying about?  And any quick thoughts on what might have
>> changed?
> 
> it's logged as warning because normally it shouldn't happen.
> i'd say it's definitely something worth to further investigate.
> i can't find the warning in my logs therefore i guess it's
> related to your custom AccessManager code.
> 
> do you share the same session with multiple threads?
> 

On closer inspection, it seems the issue is in
ItemManager.getItem(ItemId).

Previously (v. 1.0.1), this method called the AccessManager
first, then checked the cache, then created the node if necessary.
Now it seems an optimization has been made where it checks
the cache first, and skips the access check if it is cached.
In our case, the node actually gets pulled into the cache
by a custom access manager, in between the cache check
and the creation of the item, hence the warning.  But
more seriously, the access check might not even be
enforced later, since the node was added to the cache.

It may not be a common need, but does it seems the old version
was much preferable for us.  Also, if I understand it correctly, it
is a little risky using the cache to enforce the access
check, and this might affect others...  For instance, couldn't
some access manager implementations revoke read access
even after an item has been read once previously in a
(perhaps long-lived) session?  (In fact, the old implementation
seemed to accomodate this explicitly, as it evicted the node 
from cache on access failure.)

Thanks again.

Cheers,
Joshua

-- 
View this message in context: http://www.nabble.com/ItemManager-warning-tf2541411.html#a7128759
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.