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, 24 Jul 2017 23:51:08 -0000
Message-ID: <150094026888.19603.13828950918297290235@moin-vm.apache.org>
Subject: =?utf-8?q?=5BJackrabbit_Wiki=5D_Update_of_=22Overlay_Blob_Store=22_by_Mat?=
 =?utf-8?q?tRyan?=
Auto-Submitted: auto-generated
archived-at: Mon, 24 Jul 2017 23:51:15 -0000

Dear Wiki user,

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

The "Overlay Blob Store" page has been changed by MattRyan:
https://wiki.apache.org/jackrabbit/Overlay%20Blob%20Store

New page:
=3D Overlay Blob Store =3D

=3D=3D Overview =3D=3D
The overlay blob store is a multi-source blob store - a logical blob store =
consisting of at least two delegate blob stores.  In the case of the overla=
y blob store, the union of all the data in all the delegate blob stores is =
presented to a user of the overlay blob store as a single logical "view" of=
 the data being stored.

Example:

'''Delegate Blob Store A'''
 * FileA
 * FileC
 * FileE

'''Delegate Blob Store B'''
 * FileB
 * FileE
 * FileF
 * FileG

'''Overlay Blob Store View'''
 * FileA
 * FileB
 * FileC
 * FileE
 * FileF
 * FileG

The delegates for the overlay blob store are specified in configuration.  P=
art of the configuration must include an indication of the priority of each=
 delegate blob store.  Reads and writes will be attempted in the order spec=
ified by the priority.

=3D=3D=3D Reads =3D=3D=3D
The overlay blob store fulfills read requests by attempting to satisfy the =
read request from each delegate.  The read is issued to each delegate in pr=
iority order.  Once a read is successfully satisfied by a delegate, the res=
ult of the delegate read is returned as the result of the overlay blob stor=
e read and no subsequent reads are attempted for that request.  It is possi=
ble for a blob to exist in more than one delegate.

=3D=3D=3D Writes =3D=3D=3D
The overlay blob store fulfills write requests by attempting to write to ea=
ch delegate in priority order.  Once a write is successfully satisfied by a=
 delegate, the result of the delegate write is returned as the result of th=
e overlay blob store write and no subsequent writes are attempted for that =
request.

=3D=3D=3D Read-Only Delegates =3D=3D=3D
The overlay blob store supports the notion of a read-only delegate blob sto=
re.  One or more of the delegate blob stores can be configured in read-only=
 mode, meaning that it can be used to satisfy read requests but not write r=
equests.  An example use case for this scenario is where two content reposi=
tories are used, one for a production environment and one for a staging env=
ironment.  The staging repository can be configured with an overlay blob st=
ore that accesses to the production storage location in read-only mode, so =
tests can execute in staging using production data without modifying produc=
tion data or the production store.

Reads issued to a read-only delegate would be processed as normal.  Writes =
issued to a read-only delegate would fail, causing the overlay blob store t=
o move on to the next delegate to attempt to fulfill the write request.

Note that configuring all delegates of an overlay blob store would make the=
 blob store useless for storing blobs and thus should not be an allowed con=
dition - at least one delegate blob store must not be a read-only delegate.