db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Noll <dan...@nuix.com>
Subject Re: ERROR XSAI2: The conglomerate requested does not exist.
Date Mon, 14 May 2007 00:04:33 GMT
On Saturday 12 May 2007 01:47:30 Stanley Bradbury wrote:
> A conglomerate is a data or index file in Derby.  The message means
> conglomerate number 113 was referenced but could not be found.  It
> appears the object was an index that was referenced in the cache but I
> can't tell much else from the stack trace.  Files are removed when
> objects are dropped but this should not result in an error.  Was this a
> fatal error or did processing continue uninterrupted?
>
> Could you supply additional information regarding the processing that
> was happening at the time the check point was issued and the version
> being used?  Would you post the information in the derby.log so we have
> any additional information reported by the server?  It would be good to
> try and  understand what might have caused this.

As far as I can tell from the logs, this was happening right after inspecting 
the schema (metadata) to determine what version the schema is.  For a while 
we didn't keep an explicit version number table anywhere in the database, so 
for older databases we guess the schema version by looking at what tables are 
present.

Right before closing the Connection we checkpoint (I can't remember why but 
there was a very good reason for it.)  Though in this case obviously no 
changes had actually occurred to the database.

So in some sense the error was fatal (it did throw an exception, afterall, 
which we can catch but not necessarily know what to do with afterwards, so we 
throw an exception ourselves.)  But since no modifications actually occurred, 
I guess there isn't any real harm.

I'll see if I can get access to the derby.log file.

Other than that, could this perhaps be a permissions issue?  One of the things 
customers consistently fail at is that they go and haphazardly modify the 
permissions on files without knowing what will happen, rather than just 
blocking access to the top-level directory entirely, resulting in a directory 
with mixed permissions. :-/

Daniel


-- 
Daniel Noll
Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://nuix.com/                               Fax: +61 2 9212 6902

Mime
View raw message