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 >> >> >
