jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Isolation level inconsistency.
Date Tue, 24 Jul 2007 10:10:07 GMT

> > And here is a real-life use cases.

I think there is an obvious real-life use case that does need the transient changes to be
visible in the QueryResult:  We are using jackrabbit to expose a facetted navigation, so regardless
the hierarchical structure in which nodes are stored in jackrabbit, we offer a facetted navigation
view for users in which they define the way they want to navigate (~search) through the content

Now, if somebody changes a property value of a facet (ie, a drag drop move of a document in
a facet view is changing a facet value), this change stays in his transient session. Since
the facetted view is a view totally based on queries, this means that the change is only visible
*after* a session save / commit. To automatically save/commit any change of a user when it
affects a facet value does seem inferior to me: I haven't sorted all out yet, but I suppose
indexing is done by a (background) queue running every X sec...But, I need the index updated
instantly, because can't have the client waiting for a background queue to finish. 

IMO, facetted navigation is becoming more and more popular, customers are getting used to
this "new" way of browsing, and it seems to me a very real-life use case where the current
implementation is less useable. Obviously a "QUERY_TRANSIENT_CHANGE_VISIBILITY" would be great
IMO. OTH, I do think that it is quite a bit harder to implement this transient visibility.


> >
> > Imagine you are creating/editing a document where you need 
> to add a contact
> > and happened that contact is not there so you add the 
> contact, but you can't
> > save it yet because you are creating/editing a document, 
> but you need to
> > look-up this contact to add to the document, so you run a query ...
> Would you design a relational database client that leaves a
> transaction open like that for extended amounts of time? I don't think
> that's best practice.
> In fact I think JCR is better suited for managing such long-lived
> draft content for the very reason that the transient changes are
> clearly separate from the persistent storage and can be handled
> entirely on the client side of a client-server model. A relational
> database typically (at least) write-locks all rows that are being
> modified in a transaction.
> BR,
> Jukka Zitting
View raw message