Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <1916674571.20050416201707@freemail.hu>
References: <181174235.20050416061620@freemail.hu>
 <426119F3.4060809@jboss.com> <1916674571.20050416201707@freemail.hu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <975854ad4a65e77fa5c306316bbfe531@gbiv.com>
Content-Transfer-Encoding: 7bit
From: Roy T. Fielding <fielding@gbiv.com>
Subject: Re: Getting "custom" objects from the repository?
Date: Sat, 16 Apr 2005 11:34:26 -0700
To: jackrabbit-dev@incubator.apache.org

On Apr 16, 2005, at 11:17 AM, Daniel Dekany wrote:
> Assume I start transaction, modify a script
> and a template in the repository, and then commit the transaction. Now,
> when you start a new transaction later (e.g. for satisfying a HTTP
> request), you want to see the new objects, not the old ones, especially
> if you want to check what you have just committed. Also, you don't want
> to face with inconsistent states, where for example the script object 
> is
> in its old state, and the template object is in new state (since in
> general the old template works correctly only with the old script, and
> the new template works correctly only with the new script, and mixing
> the two will result in error 500 pages and other malfunctions). It's
> basically the same as the ACID thing of the RDBMS-es, and surely I 
> don't
> need to explain why is this absolutely important for server side
> applications.

Yes.

> Now, on the JCR level everything is "ACID" (well, it can
> be if transactions are supported etc). But you will seldom use raw JCR
> without some kind of object mapping behind it, right?

Behind what?  JCR?  JCR has an implementation behind it (Jackrabbit)
and that implementation will have some kind of resource mapping, but
that certainly doesn't change the ACID properties.

> And if all the
> "ACID" loses with the object mapping (as the cache can't be kept
> precisely in sync with the content of the repository), then in practice
> you have just trashed the ACIDity of the JCR repository. Does anybody
> get what I'm saying?

No, you are making too many assumptions.  If the cache is not watching
for write actions and invalidating on successful writes, then it isn't
a valid cache.  It doesn't matter whether it is above JCR or within
the JCR implementation, it would still be an invalid cache.  There are
plenty of ways to implement a cache such that it never becomes invalid.

....Roy