jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsirkin Evgeny <tsir...@gmail.com>
Subject Is Jackrabbit right for me
Date Wed, 20 Oct 2010 13:54:29 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message