Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Sat, 16 Apr 2005 23:24:21 +0200
From: Daniel Dekany <ddekany@freemail.hu>
Reply-To: Daniel Dekany <ddekany@freemail.hu>
Message-ID: <1975422982.20050416232421@freemail.hu>
To: Julien Viet <jackrabbit-dev@incubator.apache.org>
Subject: Re: Getting "custom" objects from the repository?
In-Reply-To: <42617802.9090403@jboss.com>
References: <181174235.20050416061620@freemail.hu>
 <426119F3.4060809@jboss.com>
 <1916674571.20050416201707@freemail.hu> <42617802.9090403@jboss.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Saturday, April 16, 2005, 10:39:30 PM, Julien Viet wrote:

> ok for 1/ but 2/, isnt the notification synchronous ? (even if the spec
> does not mandate it).

The specification says:

  This specification defines only asynchronous event delivery. It is
  possible for a repository to also implement synchronous events in
  order to support the vetoing of changes before they happen. However,
  this functionality is outside the scope of this specification.

As it is "outside the scope of the specification", you don't even have
Repositiry.OPTION_SYNCHRONOUS_OBSERVATION_SUPPORTED or something like
that, so the object mapper can't check if it can work correctly over the
JCR implementation in use or not.

Then, from the API docs of javax.jcr.observation.EventListener:

  An EventListener can be registered via the ObservationManager object.
  Event listeners are notified asynchronously, and see events after they
  occur and the transaction is committed. An event listener only sees
  events for which the session that registered it has sufficient access
  rights.

which is absolutely not encouraging. Especially note that last sentence.
Because, it doesn't mater who has modified the node, if it has modified,
the cache system must realize that it is out of sync, so it never serves
outdated objects (that would ruing the "ACID").
  
Then, I'm not 100% sure about this one, but I think event listeners are
running inside the repository server, and not inside the repository
client. And since the cache is (typically) in the client's JVM, the
event listeners had connect back to the client's JVM somehow to send the
notifications... lot of complication and point of failure. And if the
event notification is synchronous, then it possibly causes serious
performance degradation, since then the commitment of the transaction is
done only if the event listener has completed the notification of the
cache system.

-- 
Best regards,
 Daniel Dekany