[Jackrabbit Wiki] Update of "DataStore" by ThomasMueller

[Apache Wiki <wi...@apache.org>]

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:
http://wiki.apache.org/jackrabbit/DataStore?action=diff&rev1=43&rev2=44

  == File Data Store ==
  
  The file data store stores each binary in a file. The file name is the hash code of the content. When reading, the data is streamed directly from the file (no local or temporary copy of the file is created). 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 to the right place.
+ 
+ Because the data store is append-only, the FileDataStore is guaranteed to be consistent after a crash (unlike the BundleFsPersistenceManager). It is usually faster than the database data store, and the preferred choice unless you have strict operational reasons to put everything into a database.
  
  ==== Configuration ====
  
@@ -173, +175 @@

  
  == Future ideas ==
  
- Theoretically the data store could be split to different directories / hard drives. 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.
+ 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.
  
  Other feature requests:
   * A replicating data store