jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Behaviour when removing nodes...
Date Wed, 02 Nov 2011 09:30:32 GMT
Hi there,

i do not have a clear idea about what happens in two defined situations
when operating against a repository.

The first situation is what truly happens when deleting a node with a
binary property. My repository stores mainly nodes with the following

   -- jcr:content (nt:resource type)
           -- "some custom properties with String values"
           -- jcr:data (a potentially large Binary object)

Normaly i invoked the remove() method over the nt:file node described above
(let's say the root of the "file structure"). But when i check the
datastore placed in my hard disk it still contains the file that
corresponds to the Binary property just deleted. At this point two
questions arise: should i remove the entire structure of the nt:file node
(invoking dispose() method i guess) to actually erase the contents on disk?
and, what happens when other nodes contain the same Binary object that
corresponds to the same file deleted on disk, will such links be broken?,
does dispose() "perform smartly" like removing links on Linux (the file is
actually removed only when the last link is removed)?

The other question regards to hashing method used when storing files on the
harddisk. I found that regardless of the name and times uploaded, when a
file is stored it is named with the hash of the content. So if i upload the
very same file 2 or more times (even with distinct names) just one copy
will lay in the hard disk. Having this in mind i supposed that, in case the
file is already present on the repository, no upload would be performed
(just by checking if the "local hash" is already present) and thus a great
increase in performance would be obtained. But instead it seems that the
upload effectively takes place.

Can somebody clarify this two questions or point me to related

Thanks in advance for your attention!

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