jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Working on JR Future idea
Date Sat, 10 Mar 2012 21:51:09 GMT
Hi there,

i am working on the following "future idea"

*Client should first send the checksum and size of large objects when they
store something (import, adding or updating data), in many cases the actual
data does not need to be sent.*

found in


So far i checked both extremes (repo client and repo service) and i think i
reached the responsible classes for the sending / receiving the file to be
(potentially) stored:

(1-client  ------------------------------------------------- network
------------------------------------- 2-JR webapplication)


* For JR 2.2.7 source code.

So, the point i am now at is trying to understand all the prior checkings
that are done on both sides in order to include this improvement in the
correct place within code (please tell me if i'm wrong so far). Anyway i
would like to ask to any JR master that reads these lines about some issues:

- i noticed that JR correctly exposes the files uploaded twice (one file,
multiple URLs). Can i assume that such links will be deleted when running
the garbage collection? (i.e.: a single file exposed through multiple
links, deleting links doesn't delete the file - except for the last link -,
isn't it?)

- the FileDataStore class directly accesses the underlying SHA1-based
folder structure on disk but, which would be the best way to ask about such
structure to the server side from the client side?

- my guessing now is that the best way to introduce this new behaviour
would be in the prior checkings to the javax.jcr.Session save() method (ask
the server side and if present behave just like now but saving the network

- what would be more efficient? Checking in the inUse map (large but in
main memory) about the existence of the received-from-the-client hash or
checking for the existence of a the file (simple but accessing the hard

- ... am i missing something relevant?

Thank you very much in advance for your attention!!!

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