jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Connor, Brett (LNG-TWY)" <Brett.Con...@lexisnexis.co.uk>
Subject RE: referential integrity in the DB BPM
Date Tue, 31 Mar 2009 09:14:48 GMT
> 
> On Mon, Mar 30, 2009 at 6:24 PM, Connor, Brett (LNG-TWY) 
> <Brett.Connor@lexisnexis.co.uk> wrote:
> > Agreed, I'm certainly not proposing modifying the tables, I 
> was kind 
> > of hoping that there is some ability planned to do this, or (very
> > optimistically!) someone with knowledge could point at some cunning 
> > ideas that I haven't thought of. Data integrity doesn't 
> strike me as 
> > something that should be outside the realm of a CMS, 
> especially as you 
> > say because the tables should be black-box to applications.
> 

[JZ]
> Jackrabbit (as the content repository) should always ensure 
> the integrity (including referential integrity) of all the 
> content you store in the repository. Failure to do so is an 
> error in Jackrabbit.

Or someone performing a manual process such as restoring a QA baseline
or upgrading a server version and doing it badly, or a misconfigured
cluster, or ...

> It would be useful if you could better qualify the 
> NoSuchItemStateException issues you're seeing.

At times we get told that "it's not working" and when we look at the
system discover lots of these exceptions, sometimes from versioning but
not always. I've looked at the exception stacks but that's not that
helpful, I don't want to know what is broken, I want to know how. By the
time we get to see it it's been not working for days or weeks, and we
don't have information about exactly what has been done to the system.

> By design Jackrabbit does *not* rely on an underlying 
> database for referential integrity or conformance with node 
> types, as those checks are handled above the persistence 
> manager layer.

Indeed. The trouble for us is a) other 'processes' manipulate the
database at times, at least for admin reasons, b) the system doesn't
have people's confidence because they see a lot of these errors,
regardless of whether it is a manual process, misconfiguration, or
JackRabbit bug that's causing the corruption.

Therefore, to prove the point at the point of error, underlying storage
system constraints that do nothing but assert the same constraints that
JackRabbit is as you say handling within itself *should* make no
difference to a correctly configured running system but *would* capture
the cause of these errors real time, rather than when someone first
visually notices an error and the context has gone. It's very likely
these are all configuration or manual errors, but I have no evidence,
storage constraints applicable to the PM would give us that evidence and
confidence.

> Lower levels of data integrity (stored data 
> remains the same unless explicitly changed, changes are 
> atomic, etc.) are within the scope of the PM layer, and 
> currently Jackrabbit delegates those responsibilities to the 
> underlying database or file system.

Regards
Brett

LexisNexis is a trading name of REED ELSEVIER (UK) LIMITED - Registered office - 1-3 STRAND,
LONDON WC2N 5JR
Registered in England - Company No. 02746621


Mime
View raw message