Hi, I believe Oak has no notion of requests - the 1-1 binding of a request to a session is done in Sling. However, having said that: I was not aware of all the complexities you mention. To add one more: probably the design would have to encounter for different clustered Sling instances (that share 1 repository) that receive chunks belonging to the same binary. Is that right?
Afaik branches are not exposed into userland, but are an implementation detail. When I made my comment below, I did not realize that in order for this to work branches would have exposed. I am not sure if that's a good idea. Also not sure if it would even solve the problem. Maybe a better approach could be to persist the chunks in a temp space, similar to what Marcel suggested. But maybe that temp space could be a functionality of the datastore (I believe Marcel suggested to create a temp location by the user itself via the JCR API) Michael Sent from a mobile device _____________________________ From: Ian Boston <i...@tfd.co.uk<mailto:i...@tfd.co.uk>> Sent: Wednesday, September 7, 2016 9:36 AM Subject: Re: Seekable access to a Binary To: <oak-dev@jackrabbit.apache.org<mailto:oak-dev@jackrabbit.apache.org>> Hi, On 6 September 2016 at 18:00, Michael Marth <mma...@adobe.com<mailto:mma...@adobe.com>> wrote: > Hi, > > I think it would be neat if we could utilize our existing mechanism rather > than a new flag. In particular, MVCC and branches for session isolation. > And also simply use session.save() to indicate that an upload is complete > (and the branch containing the binaries/chunks can be merged). > Do branches and sessions hang around between requests ? Each body part will come from different requests, sometimes separated by hours and possibly even from different source IP addresses, especially under upload restart conditions. At present, in streaming mode, as each body part is encountered a session.save is performed to cause JCR/Oak to read that input stream from the request, since JCR does not expose anything that can be used to write binary data to the repository. Best Regards Ian > > Michael > > Sent from a mobile device > > > > > On Tue, Sep 6, 2016 at 1:15 PM +0200, "Marcel Reutegger" < > mreut...@adobe.com<mailto:mreut...@adobe.com><mailto:mreut...@adobe.com>> > wrote: > > Hi, > > On 06/09/16 12:34, Bertrand Delacretaz wrote: > > On Tue, Sep 6, 2016 at 9:49 AM, Marcel Reutegger > > <mreut...@adobe.com<mailto:mreut...@adobe.com>> > wrote: > >> ...we'd still have to add > >> Jackrabbit API to support it. E.g. something like: > >> > >> valueFactory.createBinary(existingBinary, appendThisInputStream); ... > > > > And maybe a way to mark the binary as "in progress" to avoid > > applications using half-uploaded binaries? > > This can easily be prevented if the 'in progress' binary is > uploaded to a temporary location first and then copied over > to the correct location once complete. Keep in mind that > copying a large existing binary in Oak is simply a cheap > copy of the reference. > > Regards > Marcel >
