Yes, the LengthCachingDataStore is exactly the way to go. You need to wrap the original datastore in the length caching datastore (using the repository.xml). The LengthCachingDataStore not only caches the length, but (for the FileDataStore at least) it also prevents a call to File.exists(). These add up on the FS and I expect even more so on S3.
Should we automatically wrap the DS in the LengthCachingDatastore in oak-upgrade? Or provide an option for the cache-file path, which turns it on if set? Regards Julian On Mon, Feb 29, 2016 at 3:17 PM, Tomek Rekawek <[email protected]> wrote: > Thanks Chetan, I haven’t noticed the length() invocation in the createBlob(). > It seems that the LengthCachingDataStore is something I was looking for. > > Best regards, > Tomek > > -- > Tomek Rękawek | Adobe Research | www.adobe.com > [email protected] > >> On 29 Feb 2016, at 14:35, Chetan Mehrotra <[email protected]> wrote: >> >> On Mon, Feb 29, 2016 at 6:42 PM, Tomek Rekawek <[email protected]> wrote: >>> I wonder if we can switch the order of length and identity comparison in >>> AbstractBlob#equal() method. Is there any case in which the >>> getContentIdentity() method will be slower than length()? >> >> That can be switched but I am afraid that it would not work as >> expected. In JackrabbitNodeState#createBlob determining the >> contentIdentity involves determining the length. You can give >> org.apache.jackrabbit.oak.upgrade.blob.LengthCachingDataStore a try >> (See OAK-2882 for details) >> >> Chetan Mehrotra >
