jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: refresh method or version stamp
Date Sun, 17 Apr 2005 12:11:45 GMT
Sunday, April 17, 2005, 6:25:39 AM, Roy T. Fielding wrote:

> On Apr 16, 2005, at 4:41 PM, Daniel Dekany wrote:
>> For example, the specification should introduce nt:monitored (don't 
>> deal
>> with the poor name choice for now...), that should mean that the node
>> has these properties:
>>
>> - jcr:uuid
>> - jcr:modificationCounter which is automatically created and 
>> initialized to
>>   0, and whose value is *automatically* incremented whenever a 
>> property of
>>   the node is written. Yeah, there are lot of unclear things about 
>> this,
>>   it was just a quick starting-point idea.
>>
>> This would be enough to implement a client side object cache 
>> ("mapping")
>> that I have talked about. If the uuid or modificationCounter of the 
>> node
>> returned for "foo/index" is changed, then the cached object shouldn't
>> be
>> used. Furthermore I think that there should be a method in the JCR API
>> for this check, so implementations can optimize this (IMO) frequent
>> task.
>
> Ah, okay, now i get it -- you want something equivalent to HTTP's
> etag header field, and its corresponding If-match conditional methods.

No, I don't necessary want that. I want to solve a very concrete task
(Should I repeat what's that? I think it was clearly described in the
earlier mails, but tell me if not.), and the above was just a quick idea
on how it should be done, what JCR feature would make it possible to
solve. I don't state this is a good way of solving the task, but maybe
it is.

> Is there some reason why Item.refresh(false) does not do exactly
> what you want, namely pick up any changes that have been persisted?

I think looking into the specification and into the API docs, it reveals
that Item.refresh(...)is not good for that, it's about something
different.

> Note that the API does not need to reveal how it determined that
> the node changed, so we don't even need a standard property name
> like jcr:versionStamp (which is good since many systems will
> already be storing internal version numbers per node).  The
> implementation behind JCR can add whatever it needs to its own
> node structures in order to make the check efficient.

Yeah, I like this approach, that there are no visible jcr properties for
that. But anyway any JCR feature would by fine by which you can ensure
that the objects cache doesn't serve outdated objects. The problem is
that there none yet. I just can't implement that cache, and that cache
definitely needed for the more serious objects that are not just
lightweight beans that you can create every time you run a query (like
with Hibernate). And I state this *is* a problem, much bigger problem
that it was with RDBMS-es (where you had the same problem anyway). But
again, please see my earlier letters, because I'm would just repeating
myself here.

> This still doesn't have anything to do with ACID or ORM, so
> that's why it was so hard to understand your concerns.

OK, referring to ACID is not precise, but I have described with concrete
examples earlier how does "ACID" come here... out-of-sync cache that
spoils A or maybe even C. Regarding ORM, that was not me who has started
to refer to ORM, but actually the guy was right that what I want is
something very similar. Just as I explained in detail in an earlier
mail, Hibernate-style ORM-s don't work in this case.

> ....Roy

-- 
Best regards,
 Daniel Dekany


Mime
View raw message