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 11:59:35 GMT
Hi,

On 12/11/06, Miro Walker <miro.walker@gmail.com> wrote:
> On 12/11/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> > 3. Rearrange the versioning operations so that modifications in the
> > version storage are always committed before modifications in the
> > normal workspace.
>
> Yeah - we discussed this as well, and it seems like a sensible
> short-term workaround although it's masking rather than solving the
> issue.

Agreed.

> The rather worrying thing at the moment is that all of the
> transaction roll-backs we've seen have been software rather than
> hardware or network failures (NPEs, etc.).

Good point.

> > 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.
>
> The real issue for us has been around workspace management - if a
> workspace is created on the fly (as we do using workspaces to model
> releases), then the DB FS is essential. In a single-workspace
> environment, I can see how it might be less interesting.

OK, understood.

> Have you or anyone else started thinking about a wish-list for a next
> major release and/or a timeframe? I'm guessing you're waiting to be
> driven by jsr-283?

My current thinking is to model Jackrabbit 2.0 as a feature release
for JSR-283. We will need to get started with the new features already
well before JSR-283 is final, since the Jackrabbit codebase will
likely be used for the reference implementation just like in JSR-170.

Other than JSR-283 there are however a number of features (both
functional and non-functional) that would be very nice to plan for
2.0/3.0. I however avoid making too extensive wish lists or tight
roadmaps for the future releases, since the open development process
makes it hard to estimate when, how, or by whom various features are
implemented. In other words, the Jackrabbit release plans follow the
implementation efforts, not the other way around.

So, the best way to get major new features or changes included in
future releases is to file Jira issues and start discussing the
changes on this list. Once an effort is substantial enough I'll most
likely get it included in the tentative release plans and it will
actually start affecting the release date and contents.

BR,

Jukka Zitting

Mime
View raw message