Hi Jukka,
On 12/11/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
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
issues.
Yeah - we discussed this as well, and it seems like a sensible
short-term workaround although it's masking rather than solving the
issue. 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.).
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.
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
Jackrabbit.
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?
Cheers,
miro
