Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 4812 invoked from network); 4 Feb 2008 17:41:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Feb 2008 17:41:49 -0000 Received: (qmail 40039 invoked by uid 500); 4 Feb 2008 17:41:41 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 40004 invoked by uid 500); 4 Feb 2008 17:41:40 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 39995 invoked by uid 99); 4 Feb 2008 17:41:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2008 09:41:40 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of marcel.reutegger@gmx.net designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 04 Feb 2008 17:41:11 +0000 Received: (qmail invoked by alias); 04 Feb 2008 17:41:17 -0000 Received: from adsl-84-226-60-53.adslplus.ch (EHLO [10.0.1.199]) [84.226.60.53] by mail.gmx.net (mp040) with SMTP; 04 Feb 2008 18:41:17 +0100 X-Authenticated: #894343 X-Provags-ID: V01U2FsdGVkX1+MlRREAEWM4eFFcDNew6be1menHc8wwyMy4EnH3n l7JhmYA7AtJlUy Message-ID: <47A74E3C.10005@gmx.net> Date: Mon, 04 Feb 2008 18:41:16 +0100 From: Marcel Reutegger User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: synchronous item/node listeners References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org Richard Frazer wrote: > So, I'm implementing my own access manager and am storing my access control > info in a db. I'd like to be able to clean up the access control info at > the time that a node is deleted within the same XA transaction as the node > being deleted. My ideal solution would be a synchronous listener that would > be fired at the time of the delete, in which I can abort the delete if the > access control info for some reason couldn't be deleted from the db. So > far, the only listeners I have found are asynchronous and occur outside the > transaction boundary. Any help would be appreciated. if your listener implements org.apache.jackrabbit.core.observation.SynchronousObservationListener it will be notified synchronously *after* the transaction has been committed. please note that the listener cannot veto the change, since it has already been committed. regards marcel