Is Jackrabbit right for me

[Tsirkin Evgeny <ts...@gmail.com>]

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.

[2] Concurrent writes are not allowed to the same node's children even if
this is a child addition.
If all this is right ,it is a real show stopper.

I gathered all this from reading this thread:
http://www.mail-archive.com/users@jackrabbit.apache.org/msg16089.html
and this blog:
http://blog.tfd.co.uk/2010/10/15/jackrabbit-performance/
plus some other resources but those are the main one.

Although JCR and Jackrabbit seems to be a real fit for my hierarchy based
task it,because of JCR's
hierarchy nature, it may well be that it is not that good fit because other
problems and I better look for other
JCR or not JCR based solutions.

Thanks
Evgeny

Re: Is Jackrabbit right for me

[Alexander Klimetschek <ak...@day.com>]

On Wed, Oct 20, 2010 at 15:54, Tsirkin Evgeny <ts...@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