Hi Tarek,
Unfortunately I don't know whether such scenario can be handled by
Jackrabbit.
I've never used the JCR lock feature so far, but I hope you'll be able
to bend it to your will.
Cheers,
Jarek
On 11.10.2014 10:17, Tarek Jarraya wrote:
Hi Jarek,
Thank your for your detailed reply.
In fact, in my case, the subtree is built based on a series of "user"
requests, each request use a JCR session from the pool. More precisely, I
am adding to the repository many documents, and all of them should be in
one transaction. If the insert of one of them fails, all the subtree should
be removed.
My thought now is, trying to use the JCR Lock feature that will take care
of concurrent access on the subtree. For subtree change hidding until
commit, I will try to combine root node versioning (i.e. when we update a
graph) and an application property like available=false.
Is there more simpler solution for this request?
For JCR Lock, is it possible lock a node only for read? Is it possible to
apply Node lock just for specific node version?
Thanks,
Tarek
On Fri, Oct 10, 2014 at 7:09 PM, Jaroslaw Marek <[email protected]>
wrote:
Hi Tarek,
Is it required for you to create a child node in a separate request?
Couldn't it be done in one request using one session? Could you describe
your usage scenario in more detail?
It seems that our usage scenario have some similarities with yours, so I
will describe it:
* we use Jackrabbit to store images
* when user uploads an image, we also create two thumbnails for it, so in
the end we have one parent node (original image) and two child/referenced
nodes (thumbnails)
* we do all that during one request (between user and the app) and
multiple calls to Jackrabbit (app -> jackrabbit) within one JCR session
* we use the same approach while updating the image (replacing binary
content). We leave the nodes with their properties intact and just replace
their binary content.
If it would be feasible for you to use such approach, I would recommend it.
Unfortunately I don't know whether it is possible to span a transaction
across many sessions, but I doubt it.
Cheers,
Jarek
On 10.10.2014 12:49, Tarek Jarraya wrote:
Hi All,
Context:
-----------
Jackrabbit v 2.8
Deployment model 3, exposed via war deployed on tomcat 7
The consumers (web application) use webdav interface
We manage a session pool. One session per request
The consumer is stateless.
Need:
-------
Be able to add a "versionable" node subtree: 1st request for the root
node,
and additional request per new child node.
All the subtree should not be available for read until all the grap is
created.
The same need for the update operation. The update will concern on a
specific version of the subtree. During the update the user should see the
old values of the version.
In my understanding, since that we don't keep a session for long time (a
session per request), we can not manage a JCR transaction to group all the
subtree operations before a commit.
I am thinking for this solution:
- Create a "tmp" node for subtree work, then I will move it in the right
place at the end.
- I don't know if this solution will work when I update an existing node.
I
don't know if I create, move or copy the node to the tmp node.
Is there a better solution to solve this problem?
Maybe we can do it with transactions. If it is true, where and how to
manage it in the consumer side? Can we have a transaction shared by many
sessions?
Thanks,
Tarek
