jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "DataStore" by ThomasMueller
Date Fri, 02 Oct 2009 07:16:25 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "DataStore" page has been changed by ThomasMueller:

  The file system must supports files as large as the largest object you want to store. Please
note that the file size limit of FAT32 is 2 GB.
+ ---- /!\ '''Edit conflict - other version:''' ----
  == How to Configure the File Data Store ==
+ ---- /!\ '''Edit conflict - your version:''' ----
+ == How to Configure the File Data Store ==
+ ---- /!\ '''End of edit conflict''' ----
  To use the file based data store, add this to your repository.xml before the </Repository>:
@@ -213, +220 @@

   1. Run gc.mark() on each repository 
   1. Manually delete files with last modified date older than X
+ ---- /!\ '''Edit conflict - other version:''' ----
  == How to Write a New Data Store Implementation ==
+ ---- /!\ '''Edit conflict - your version:''' ----
+ == How to Write a New Data Store Implementation ==
+ ---- /!\ '''End of edit conflict''' ----
  New implementations are welcome! Cool would be a S3 data store (http://en.wikipedia.org/wiki/Amazon_S3).
A caching data store would be great as well (items that are used a lot are stored in fast
file system, others in a slower one).
- == Future ideas ==
+ == Future Ideas ==
  Theoretically the data store could be split to different directories / hard drives. Currently
this can be done manually moving directories to different disks and by creating softlinks.
Content that is accessed more often could be moved to a faster disk, and less used data could
eventually be moved to slower / cheaper disk. That would be an extension of the 'memory hierarchy'
(see also http://en.wikipedia.org/wiki/Memory_hierarchy). Of course this wouldn't limit the
space used per workspace, but would improve system performance if done right. Maybe we need
to do that anyway in the near future to better support solid state disk.

View raw message