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 Suat Gonul <su...@gmail.com> on 2012/08/07 08:56:37 UTC

Non-existent conglomerate exception

Hello everyone,

I would like to know that if there would be a certain case causing the
exception below. I can't reproduce that exception regularly though. The
conglomerate number seems to be different in each case. I looked at
several issues about non-existence of conglomerate but none of them
seemed to be similar with my case. I would be very glad if you give some
possible situations which may cause this situation or point me to the
related issues if there is any.

Currently I use the 10.7.1.1 version within an OSGi environment and I
prepare and execute the PrepareStatement causing this error as follows:

ps = con.prepareStatement(SELECT id, revision FROM revisionTable WHERE
revision > ? ORDER BY revision ASC),
                    ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ps.setLong(1, revision);
ps.setMaxRows(1000);
rs = ps.executeQuery();

Best,
Suat

The stacktrace:

Caused by: java.sql.SQLException: The conglomerate (1,808) requested
does not exist.
    at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
Source)
    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.EmbedStatement.executeStatement(Unknown Source)
    at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
    at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown
Source)
    at
org.apache.stanbol.contenthub.revisionmanager.RevisionManager.getChanges(RevisionManager.java:191)
    ... 3 more
Caused by: java.sql.SQLException: The conglomerate (1,808) requested
does not exist.
    at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
    at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
Source)
    ... 13 more
Caused by: ERROR XSAI2: The conglomerate (1,808) requested does not exist.
    at
org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
    at
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown
Source)
    at
org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown
Source)
    at
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
Source)
    at
org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(Unknown
Source)
    at
org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown
Source)
    at
org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(Unknown Source)
    at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
Source)
    at
org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.openCore(Unknown
Source)
    at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown
Source)
    at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
Source)
    at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
    ... 7 more

Re: Non-existent conglomerate exception

Posted by "Dag H. Wanvik" <da...@oracle.com>.
Suat Gonul <su...@gmail.com> writes:

> After setting the derby.language.statementCacheSize property to 0, I
> have not received the exception. Maybe I should use the latest release...

Good! "latest release": Yes, good idea. I know there has been fixes in
the area of invalidating and recompilng cached prepared statements. If
you still see the issue, we'd love to get a repro :)

Thanks,
Dag

>
> Best,
> Suat   
>
>
> On 08/07/2012 05:05 PM, Dag H. Wanvik wrote:
>> Suat Gonul <su...@gmail.com> writes:
>>
>>> Thanks for the answer! Yes, I also suspected from such a condition and
>>> yes, my application does concurrent changes to the revisionTable. One
>>> thread might insert records into the revisionTable while the others
>>> query/update it.
>> At the outset, only changes to the table's schema or creating/dropping
>> indexes on it should affect the prepared statement. Plain inserts,
>> deletes and updates should not.
>>
>>> So, how should I handle this case? Is it possible to invalidate the
>>> PreparedStatement explicitly?
>> I think you can work around it by setting the size of the
>> derby.language.statementCacheSize property to 0.
>>
>> Then every prepare you do will actually compile the query.  Would be
>> interestng to see it that removed the issue.
>>
>>
>> Thanks,
>> Dag
>>
>>

Re: Non-existent conglomerate exception

Posted by Suat Gonul <su...@gmail.com>.
After setting the derby.language.statementCacheSize property to 0, I
have not received the exception. Maybe I should use the latest release...

Best,
Suat   


On 08/07/2012 05:05 PM, Dag H. Wanvik wrote:
> Suat Gonul <su...@gmail.com> writes:
>
>> Thanks for the answer! Yes, I also suspected from such a condition and
>> yes, my application does concurrent changes to the revisionTable. One
>> thread might insert records into the revisionTable while the others
>> query/update it.
> At the outset, only changes to the table's schema or creating/dropping
> indexes on it should affect the prepared statement. Plain inserts,
> deletes and updates should not.
>
>> So, how should I handle this case? Is it possible to invalidate the
>> PreparedStatement explicitly?
> I think you can work around it by setting the size of the
> derby.language.statementCacheSize property to 0.
>
> Then every prepare you do will actually compile the query.  Would be
> interestng to see it that removed the issue.
>
>
> Thanks,
> Dag
>
>

Re: Non-existent conglomerate exception

Posted by Suat Gonul <su...@gmail.com>.
On 08/07/2012 05:05 PM, Dag H. Wanvik wrote:
> Suat Gonul <su...@gmail.com> writes:
>
>> Thanks for the answer! Yes, I also suspected from such a condition and
>> yes, my application does concurrent changes to the revisionTable. One
>> thread might insert records into the revisionTable while the others
>> query/update it.
> At the outset, only changes to the table's schema or creating/dropping
> indexes on it should affect the prepared statement. Plain inserts,
> deletes and updates should not.
>

Well, I do not create or drop indexes explicitly. Just creating tables
and do plain operations on them.

>> So, how should I handle this case? Is it possible to invalidate the
>> PreparedStatement explicitly?
> I think you can work around it by setting the size of the
> derby.language.statementCacheSize property to 0.
>
> Then every prepare you do will actually compile the query.  Would be
> interestng to see it that removed the issue.

OK. I will try that and share the results.

>
> Thanks,
> Dag
>
>

Re: Non-existent conglomerate exception

Posted by "Dag H. Wanvik" <da...@oracle.com>.
Suat Gonul <su...@gmail.com> writes:

> Thanks for the answer! Yes, I also suspected from such a condition and
> yes, my application does concurrent changes to the revisionTable. One
> thread might insert records into the revisionTable while the others
> query/update it.

At the outset, only changes to the table's schema or creating/dropping
indexes on it should affect the prepared statement. Plain inserts,
deletes and updates should not.

>
> So, how should I handle this case? Is it possible to invalidate the
> PreparedStatement explicitly?

I think you can work around it by setting the size of the
derby.language.statementCacheSize property to 0.

Then every prepare you do will actually compile the query.  Would be
interestng to see it that removed the issue.


Thanks,
Dag

Re: Non-existent conglomerate exception

Posted by Suat Gonul <su...@gmail.com>.
On 08/07/2012 02:55 PM, Dag H. Wanvik wrote:
> Suat Gonul <su...@gmail.com> writes:
>
>> Hello everyone,
>>
>> I would like to know that if there would be a certain case causing the
>> exception below. I can't reproduce that exception regularly though. The
>> conglomerate number seems to be different in each case. I looked at
>> several issues about non-existence of conglomerate but none of them
>> seemed to be similar with my case. I would be very glad if you give some
>> possible situations which may cause this situation or point me to the
>> related issues if there is any.
> One possibility is that the statement cache contains an already prepared
> statement with this string "SELECT id, revision FROM revisionTable WHERE
> revision > ? ORDER BY revision ASC" and that somehow it is no longer up
> to date. If, say, the schema of revisionTable changes or applicable
> indexes, the cached statement should have been invalidated (and
> recompiled on the next usage), but that may not have happened for some
> reason. Does you app make concurrent changes to revisionTable and/or its
> indexes?
>
> Thanks,
> Dag
>

Thanks for the answer! Yes, I also suspected from such a condition and
yes, my application does concurrent changes to the revisionTable. One
thread might insert records into the revisionTable while the others
query/update it.

So, how should I handle this case? Is it possible to invalidate the
PreparedStatement explicitly?

Best,
Suat


>> Currently I use the 10.7.1.1 version within an OSGi environment and I
>> prepare and execute the PrepareStatement causing this error as follows:
>>
>> ps = con.prepareStatement(SELECT id, revision FROM revisionTable WHERE
>> revision > ? ORDER BY revision ASC),
>>                     ResultSet.TYPE_SCROLL_INSENSITIVE,
>> ResultSet.CONCUR_READ_ONLY);
>> ps.setLong(1, revision);
>> ps.setMaxRows(1000);
>> rs = ps.executeQuery();
>
>
>> Best,
>> Suat
>>
>> The stacktrace:
>>
>> Caused by: java.sql.SQLException: The conglomerate (1,808) requested
>> does not exist.
>>     at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
>> Source)
>>     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.EmbedStatement.executeStatement(Unknown Source)
>>     at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown
>> Source)
>>     at
>> org.apache.stanbol.contenthub.revisionmanager.RevisionManager.getChanges(RevisionManager.java:191)
>>     ... 3 more
>> Caused by: java.sql.SQLException: The conglomerate (1,808) requested
>> does not exist.
>>     at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
>> Source)
>>     ... 13 more
>> Caused by: ERROR XSAI2: The conglomerate (1,808) requested does not exist.
>>     at
>> org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>>     at
>> org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(Unknown Source)
>>     at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.openCore(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
>> Source)
>>     at
>> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
>>     ... 7 more

Re: Non-existent conglomerate exception

Posted by "Dag H. Wanvik" <da...@oracle.com>.
Suat Gonul <su...@gmail.com> writes:

> Hello everyone,
>
> I would like to know that if there would be a certain case causing the
> exception below. I can't reproduce that exception regularly though. The
> conglomerate number seems to be different in each case. I looked at
> several issues about non-existence of conglomerate but none of them
> seemed to be similar with my case. I would be very glad if you give some
> possible situations which may cause this situation or point me to the
> related issues if there is any.

One possibility is that the statement cache contains an already prepared
statement with this string "SELECT id, revision FROM revisionTable WHERE
revision > ? ORDER BY revision ASC" and that somehow it is no longer up
to date. If, say, the schema of revisionTable changes or applicable
indexes, the cached statement should have been invalidated (and
recompiled on the next usage), but that may not have happened for some
reason. Does you app make concurrent changes to revisionTable and/or its
indexes?

Thanks,
Dag

>
> Currently I use the 10.7.1.1 version within an OSGi environment and I
> prepare and execute the PrepareStatement causing this error as follows:
>
> ps = con.prepareStatement(SELECT id, revision FROM revisionTable WHERE
> revision > ? ORDER BY revision ASC),
>                     ResultSet.TYPE_SCROLL_INSENSITIVE,
> ResultSet.CONCUR_READ_ONLY);
> ps.setLong(1, revision);
> ps.setMaxRows(1000);
> rs = ps.executeQuery();



>
> Best,
> Suat
>
> The stacktrace:
>
> Caused by: java.sql.SQLException: The conglomerate (1,808) requested
> does not exist.
>     at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
>     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.EmbedStatement.executeStatement(Unknown Source)
>     at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
>     at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown
> Source)
>     at
> org.apache.stanbol.contenthub.revisionmanager.RevisionManager.getChanges(RevisionManager.java:191)
>     ... 3 more
> Caused by: java.sql.SQLException: The conglomerate (1,808) requested
> does not exist.
>     at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)
>     at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
>     ... 13 more
> Caused by: ERROR XSAI2: The conglomerate (1,808) requested does not exist.
>     at
> org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>     at
> org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown
> Source)
>     at
> org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown
> Source)
>     at
> org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
> Source)
>     at
> org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(Unknown
> Source)
>     at
> org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown
> Source)
>     at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(Unknown Source)
>     at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown
> Source)
>     at
> org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.openCore(Unknown
> Source)
>     at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown
> Source)
>     at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
> Source)
>     at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
>     ... 7 more