Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of dpfister@adobe.com designates
 64.18.1.183 as permitted sender)
From: Dominique Pfister <dpfister@adobe.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: Lifetime of revision identifiers
Date: Tue, 3 Apr 2012 14:31:02 +0200
Message-ID: <9349CB01-316F-493A-8AD5-15A1ACBE13CA@adobe.com>
To: <oak-dev@jackrabbit.apache.org>
MIME-Version: 1.0 (Apple Message framework v1084)

On 3.4.12 13:36, Michael D=FCrig wrote:

> 10 minutes (like any value) seems quite arbitrary to me. I wouldn't =
want to fix deployments by fiddling around with this. Rather should =
clients be empowered to specify how long they need a certain revision =
(e.g. by a lease model as Jukka proposed).

> If a deployment runs out of space because the client application holds =
on to too many revisions for too long, this can be fixed by optimising =
the client and adjusting the store size to the actual client's =
requirements.

I don't like the idea in general, that a server compontent relies on =
clients to behave "well" or things will break. As you said, we don't =
have any conclusive figures yet, how fast things will grow in the =
revision store. It is just my gut feeling, that keeping revisions around =
as long as they're accessed, will generate other problems if we don't =
have a hard limit on a revision's overall lifetime.

Dominique=