Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <45F55E83.1020102@gmx.net>
Date: Mon, 12 Mar 2007 15:06:59 +0100
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: Database PersistenceManagers (was "Results of a JR Oracle test
 that we conducted)
References: <49977f270703020340m72621bf8n2669ccb4fc9e8be@mail.gmail.com>
	 <C20DC3B8.40C0%brdavis@bea.com>
	 <90a8d1c00703030711p198bdfafg62abcb384720f1b1@mail.gmail.com>
 <510143ac0703120631s6a64d126p2bf9a5c26069df97@mail.gmail.com>
In-Reply-To: <510143ac0703120631s6a64d126p2bf9a5c26069df97@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Jukka Zitting wrote:
>> further note that write operations must occur within a single jdbc
>> transaction, i.e. you can't get a new connection for every store/destroy
>> operation.
> 
> I think this is a design flaw. On the other hand we require
> persistence managers to be "dumb" components, but then we rely on them
> for complex features like transactions.

I'd say those components are 'simple' rather than 'dumb' or 'complex'. the 
requirements are therefore also relatively simple: operations must have A(C)ID 
properties.

A) a change log must be persisted as a whole or not at all
C) this is actually handled by the upper level
I) while a change log is persisted a read must not see partially stored content
D) durability, well you get the idea...

to implement those requirements you don't necessarily need a database (as you 
pointed out in another thread ;)).

regards
  marcel