jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Transactions & DB Persistence Managers
Date Mon, 11 Dec 2006 09:20:11 GMT

On 12/8/06, Miro Walker <miro.walker@gmail.com> wrote:
> The way jackrabbit is currently structured, if versioning is enabled
> it is not possible to achieve a truly transactionally secure
> repository.


> The reason for this is that the version history and the workspace(s)
> in which data are stored use seperate database connections. This means
> that when performing a versioning operation (e.g. checkIn) two
> seperate transactions are executed. If the second one of these fails,
> the system will only rollback this one, not the first, leaving the
> repository corrupted to an extent that it can't be recovered using the
> JCR API. E.g. a node in a workspace contains a reference to a base
> version that does not exist in the version history.
> [...]
> There appear to be two ways to resolve this issue (that I can think of):

I'll add a third one that doesn't really solve the underlying issue
about transactions, but would avoid the content integrity problems:

3. Rearrange the versioning operations so that modifications in the
version storage are always committed before modifications in the
normal workspace. Since there are no references from the version
storage to the normal workspace, this cannot introduce consistency

> How about the use of a DB persistence manager in combination with a DB
> FileSystem? Is this a common use case? We are using it because we have
> a requirement to have all non-transient data stored in a database (for
> backup / DR purposes). Suggestions we've made in the past to make it
> easier to administer have been rejected, however, so perhaps it's not
> being used much elsewhere?

I think the DB PM/FS configuration is most often covered by the
externalBLOBs configuration option that will get all ItemState content
stored in the configured PM database.

Anyway, I'm open to alternatives in this area as I agree that while
the current persistence model does work very well for the core
features, there are features that are adversely affected by the
current design. Any rework in this area will however need to take the
installed base of Jackrabbit repositories in account. Upgrades to the
persistence model would most likely mean major version updates for


Jukka Zitting

View raw message