Mailing-List: contact commits-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Mon, 21 Sep 2009 09:08:12 -0000
Message-ID: <20090921090812.22430.49273@eos.apache.org>
Subject: 
 =?utf-8?q?=5BJackrabbit_Wiki=5D_Update_of_=22DataStore=22_by_ThomasMuelle?=
 =?utf-8?q?r?=

Dear Wiki user,

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

The "DataStore" page has been changed by ThomasMueller:
http://wiki.apache.org/jackrabbit/DataStore?action=3Ddiff&rev1=3D43&rev2=3D=
44

  =3D=3D File Data Store =3D=3D
  =

  The file data store stores each binary in a file. The file name is the ha=
sh code of the content. When reading, the data is streamed directly from th=
e file (no local or temporary copy of the file is created). The file data s=
tore 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 unle=
ss you have strict operational reasons to put everything into a database.
  =

  =3D=3D=3D=3D Configuration =3D=3D=3D=3D
  =

@@ -173, +175 @@

  =

  =3D=3D Future ideas =3D=3D
  =

- Theoretically the data store could be split to different directories / ha=
rd drives. Content that is accessed more often could be moved to a faster d=
isk, 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.w=
ikipedia.org/wiki/Memory_hierarchy). Of course this wouldn't limit the spac=
e used per workspace, but would improve system performance if done right. M=
aybe we need to do that anyway in the near future to better support solid s=
tate disk.
+ Theoretically the data store could be split to different directories / ha=
rd drives. Currently this can be done manually moving directories to differ=
ent disks and by creating softlinks. Content that is accessed more often co=
uld 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 hierar=
chy' (see also http://en.wikipedia.org/wiki/Memory_hierarchy). Of course th=
is wouldn't limit the space used per workspace, but would improve system pe=
rformance 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