jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: DataStore - File or Database for an Ecommerce Web Application?
Date Wed, 15 Jul 2009 11:15:25 GMT
On Wed, Jul 15, 2009 at 10:42 AM, Gadbury<gadbury@googlemail.com> wrote:
> "The file data store does not use any local cache, that means content is
> directly read from the files as needed. New content is first stored in a
> temporary file, and later renamed / moved."

This text is 100% correct (for the file datastore).

> I assume this means that with 100 users downloading the same 100MB file, all
> downloading users will stream directly from the file and that no local /
> temporary copies of the file would be created on the server.  I'm not quite
> sure what it means by new content; does it mean that when a new file is
> added to the repository (data store), a temporary copy will be created on
> the server?

Upon saving a new binary stream via the JCR API, it will first be
saved in a temporary file internally because the datastore a) only
stores full files (there could be an error while streaming a large
binary) and b) it needs to calculate the MD5 of the file to use it as
identifier.

> When reading and downloading, are no temporary copies of the
> file created on the server when using a file data store?

Right.

> If I was to use a database data store and apply the same scenario, would 100
> local copies (on the server) of the 50MB file be created for each user
> requesting the file for download?  Or would there be just one temporary
> instance of the same file?  If that is the case, this would present a
> problem if those 100 users were each downloading different 100MB files.

AFAIK this depends on the JDBC driver of the database, but I think
most of them spool binary blobs in temporary local files. In general,
a file datastore has always very good performance and a database
datastore cannot be better - it will most likely be slower.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message