jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Isolation level inconsistency.
Date Fri, 20 Jul 2007 17:06:12 GMT

On 7/20/07, IvanLatysh <ivan@yourmail.com> wrote:
> Jukka Zitting wrote:
> > Also, I still don't think there are real use cases for the opposite
> > requirement, i.e. having transient changes visible in search.
> For me it looks like members of this list assume that we are on the webapp or
> client-server architecture where transactions are short.
> Let's move to a swing application. Embedded JCR 1 session for entire
> application, long lasting transactions (2+ hours, lunch,...,coffe,...,meeting)
> And here is a real-life use cases.
> 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.


Jukka Zitting

View raw message