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
