Hi,
On 7/20/07, IvanLatysh <[EMAIL PROTECTED]> 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.
BR,
Jukka Zitting
