You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Thomas Dudziak <to...@gmail.com> on 2005/11/09 22:36:07 UTC
"conglomerate does not exist" error
Hi folks,
I get the "The conglomerate (1.056) requested does not exist." error
with Derby 10.1.1.0 and I don't understand why. Here's the setup:
* I've created a database (using embedded driver) via DdlUtils into my
webapp-to-be-deployed in directory WEB-INF/classes/derbydb. The
database correctly contains data as I checked with ij.
* I then configured my webapp (Struts + Spring) to use Derby via the
url "jdbc:derby:classpath:derbydb" in the assumption that the
WEB-INF/Classes folder is automatically in the classpath.
* The whole stuff is packaged into a WAR and deployed into Tomcat
5.5.12 (which btw. does not know anything about the database)
* The I start the webapp and try to login which in turn uses the
database for the first time. This is where it goes bang.
Database access is configured in Spring to use the
DriverManagerDataSource, and also there is only one user (me as I'm
currently developing the webapp) and only one using class in the
webapp, so there is no concurrent access AFAIK (no multiple VMs or
classloaders).
So could perhaps somebody give me a tip what I did wrong ?
regards,
Tom
PS: here's the stacktrace as far as Derby is concerned:
Caused by: SQL Exception: The conglomerate (1.056) requested does not exist.
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy$TransactionAwareInvocationHandler.invoke(TransactionAwareDataSourceProxy.java:167)
at $Proxy1.prepareStatement(Unknown Source)
Re: "conglomerate does not exist" error
Posted by Sunitha Kambhampati <ks...@gmail.com>.
sorry - a dot is missing in the link.
correct link :
http://db.apache.org/derby/docs/10.0/manuals/develop/develop38.html
Sunitha Kambhampati wrote:
> http://dbapache.org/derby/docs/10.0/manuals/develop/develop38.html
>
>
Re: "conglomerate does not exist" error
Posted by Thomas Dudziak <to...@gmail.com>.
On 11/10/05, Sunitha Kambhampati <ks...@gmail.com> wrote:
> For using the jdbc:derby:classpath , you need to ensure that the jar
> that contains your database is in your classpath. Is it possible that
> when you restart the web server - that is when the 'jar that has the
> database' is being picked up by the web server and derby is able to use
> it ?
the database is not in a jar, but rather a directory (I want to be
able to write to it) which lives in WEB-INF/classes, and thus is
automatically in the classpath of the web app.
And as I wrote, when ij runs/was run, I somehow can use the database.
So I figured, it has something to do with the initialization of the
database files ?
Tom
Re: "conglomerate does not exist" error
Posted by Sunitha Kambhampati <ks...@gmail.com>.
Thomas Dudziak wrote:
> No, I didn't start ij from within eclipse, but rather from the
>
>commandline. And derby.home shouldn't matter when using
>jdbc:derby:classpath, right ?
>
> <>Even more interesting, I simply stopped the web server and
> restartedit without any other changes, and now access to Derby works
> without
> problems, even after additional restarts. So this has to with
> first-time access to the database ?
For using the jdbc:derby:classpath , you need to ensure that the jar
that contains your database is in your classpath. Is it possible that
when you restart the web server - that is when the 'jar that has the
database' is being picked up by the web server and derby is able to use
it ?
http://dbapache.org/derby/docs/10.0/manuals/develop/develop38.html
Sunitha.
Re: "conglomerate does not exist" error
Posted by Thomas Dudziak <to...@gmail.com>.
On 11/10/05, Knut Anders Hatlen <Kn...@sun.com> wrote:
> Just a wild guess: Starting ij in Eclipse sets derby.system.home to
> the directory where the database is located, hence the database is
> found. In the other cases derby.system.home is set to its default
> value (current working directory), which is not where the database is
> located.
No, I didn't start ij from within eclipse, but rather from the
commandline. And derby.home shouldn't matter when using
jdbc:derby:classpath, right ?
Tom
Re: "conglomerate does not exist" error
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Thomas Dudziak <to...@gmail.com> writes:
> On 11/9/05, Mike Matrigali <mi...@sbcglobal.net> wrote:
>> In the directory where your database directory is there should
>> be a file called derby.log and in it will have the part of the
>> stack I am looking for.
>>
>> Since it works in ij - it seems like the db is good - which was the
>> problem I was going to look at. It seems like there must be some set up
>> issue with your web server, hopefully someone with more experience in
>> that area can help out.
>
> Ah, yes, I found it, it landed in the eclipse root folder (I start
> Tomcat from within Eclipse), but contains nothing interesting:
>
> ----------------------------------------------------------------
> 2005-11-09 22:13:43.008 GMT:
> Booting Derby version The Apache Software Foundation - Apache Derby -
> 10.1.1.0 - (208786): instance c013800d-0107-7717-4a97-0000001ed0d0
> on database directory classpath:/derbydb
>
> Database Class Loader started - derby.database.classpath=''
>
>
> Restarting the webserver without ij running, consistently generates
> the "conglomerate" error. I also checked that it has nothing to do
> with Eclipse, and started tomcat via the startup script, and I get the
> same error.
> So somehow, ij 'fixes' the Derby instance so that I can use it
> afterwards, which is IMO quite strange.
Just a wild guess: Starting ij in Eclipse sets derby.system.home to
the directory where the database is located, hence the database is
found. In the other cases derby.system.home is set to its default
value (current working directory), which is not where the database is
located.
You can check whether this is the case by changing the connection URL
from 'jdbc:derby:derbydb' to 'jdbc:derby:/full/path/to/derbydb'.
--
Knut Anders
Re: "conglomerate does not exist" error
Posted by Thomas Dudziak <to...@gmail.com>.
On 11/9/05, Mike Matrigali <mi...@sbcglobal.net> wrote:
> In the directory where your database directory is there should
> be a file called derby.log and in it will have the part of the
> stack I am looking for.
>
> Since it works in ij - it seems like the db is good - which was the
> problem I was going to look at. It seems like there must be some set up
> issue with your web server, hopefully someone with more experience in
> that area can help out.
Ah, yes, I found it, it landed in the eclipse root folder (I start
Tomcat from within Eclipse), but contains nothing interesting:
----------------------------------------------------------------
2005-11-09 22:13:43.008 GMT:
Booting Derby version The Apache Software Foundation - Apache Derby -
10.1.1.0 - (208786): instance c013800d-0107-7717-4a97-0000001ed0d0
on database directory classpath:/derbydb
Database Class Loader started - derby.database.classpath=''
Restarting the webserver without ij running, consistently generates
the "conglomerate" error. I also checked that it has nothing to do
with Eclipse, and started tomcat via the startup script, and I get the
same error.
So somehow, ij 'fixes' the Derby instance so that I can use it
afterwards, which is IMO quite strange.
Tom
Re: "conglomerate does not exist" error
Posted by Thomas Dudziak <to...@gmail.com>.
On 11/9/05, Mike Matrigali <mi...@sbcglobal.net> wrote:
> That stack does not include the derby internal stack, perhaps you still
> have it in derby.log?
I'm not entirely sure what you mean by the derby internal stack and
derby.log ? I run derby in embedded mode, how can I direct it to
generate such a thing (the manual structure is IMO quite confusing; a
quick search did not produce anything useful about logging) ?
> You can enable properties to print which query is encountering the
> error. Then see if you can run the query in ij vs your webapp setup.
I got the query (I'm using OJB which prints out the query in case of
an error). It is:
SELECT A0.id,A0.firstname,A0.lastname,A0.username,A0.password,A0.email
FROM users A0 WHERE A0.username = 'tomdz';
When running with ij in WEB-INF/classes using the connection url
'jdbc:derby:derbydb', the above query works without problems.
Interestingly, I re-created the database, and redeployed it and now I
get a "ERROR 42X05: Table 'USERS' does not exist." error which I
think, has to do with the username and schemas. For reference, I use
the username 'app' to connect to Derby in both creation and in the
webapp so that I don't have to deal with schemas.
I'll see whether I can get the "conglomerate does not exist" error again.
Tom
Re: "conglomerate does not exist" error
Posted by Thomas Dudziak <to...@gmail.com>.
Even more interesting, I simply stopped the web server and restarted
it without any other changes, and now access to Derby works without
problems, even after additional restarts. So this has to with
first-time access to the database ?
Tom
Re: "conglomerate does not exist" error
Posted by Mike Matrigali <mi...@sbcglobal.net>.
That stack does not include the derby internal stack, perhaps you still
have it in derby.log?
You can enable properties to print which query is encountering the
error. Then see if you can run the query in ij vs your webapp setup.
Thomas Dudziak wrote:
> Hi folks,
>
> I get the "The conglomerate (1.056) requested does not exist." error
> with Derby 10.1.1.0 and I don't understand why. Here's the setup:
>
> * I've created a database (using embedded driver) via DdlUtils into my
> webapp-to-be-deployed in directory WEB-INF/classes/derbydb. The
> database correctly contains data as I checked with ij.
>
> * I then configured my webapp (Struts + Spring) to use Derby via the
> url "jdbc:derby:classpath:derbydb" in the assumption that the
> WEB-INF/Classes folder is automatically in the classpath.
>
> * The whole stuff is packaged into a WAR and deployed into Tomcat
> 5.5.12 (which btw. does not know anything about the database)
>
> * The I start the webapp and try to login which in turn uses the
> database for the first time. This is where it goes bang.
>
> Database access is configured in Spring to use the
> DriverManagerDataSource, and also there is only one user (me as I'm
> currently developing the webapp) and only one using class in the
> webapp, so there is no concurrent access AFAIK (no multiple VMs or
> classloaders).
>
> So could perhaps somebody give me a tip what I did wrong ?
>
> regards,
> Tom
>
> PS: here's the stacktrace as far as Derby is concerned:
>
> Caused by: SQL Exception: The conglomerate (1.056) requested does not exist.
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
> at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy$TransactionAwareInvocationHandler.invoke(TransactionAwareDataSourceProxy.java:167)
> at $Proxy1.prepareStatement(Unknown Source)
>
>