jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Is Jackrabbit right for me
Date Thu, 21 Oct 2010 18:46:01 GMT
On Wed, Oct 20, 2010 at 15:54, Tsirkin Evgeny <tsirkin@gmail.com> wrote:
> I have the following task for which i am researching JCR/Jackrabbit .
> This would be an internally used system.
> Mostly this is a document management system tied to the organization's
>  structure.
> Organization -> department -> sub department etc.
> Since this is a university we are talking about, at each level we have
> staff, at different levels/roles,
> and students .
> The staff is responsible for maintaining it's (sub) department document's
> and it's (sub)department student's documents.
> That basically means that each department will have a lot of "student" nodes
> and a lot of documents stored for
> the department itself.
> Different roles can have read or writes privileges.
> Now ,unlike a content management system, here I  have heavy write/update
> load with
> concurrent reads and writes.
> What I am mostly worried about is a concurrency problems I have read about
>  .
> What I understand is that Jackrabbit does not support :
>
> [1] Concurrent request while a session have write rights will block and
> evaluated in single thread.
> That means that several users logged in as write enabled (and those would be
> the most of my users)
> will have their requests executed in a single threaded mode.

Well, there must be a place where writes are synchronized somehow!
Depending on the type and amount of writes (and conflicts) one can get
more performant with synchronizing at a lower layer or using MVCC, but
that depends.

Anyway, a web application using Jackrabbit easily supports multiple
users. Also "write enabled" is not the same as actual writes (most
requests in any web app are read-only). It boils down to how many
writes are concurrently happening at the same time and if Jackrabbit
and the persistence configuration are up to speed (ie. synchronization
doesn't slow down requests too much), which needs to be evaluated.

> [2] Concurrent writes are not allowed to the same node's children even if
> this is a child addition.

AFAIK this has been improved in 2.1 already, so that these can be
merged without forcing a conflict.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message