db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: "Conglomerate could not be created"?
Date Wed, 20 Jun 2012 08:45:01 GMT
On 19.06.2012 09:45, John English wrote:
> On 05/06/2012 18:45, Dag H. Wanvik wrote:
>>
>> Looks like a bug to me. The error "XSCH4 Conglomerate could not be
>> created" isn't being tested for in the Derby tests as far as I can
>> see. I also searched the bug tracker
>> (https://issues.apache.org/jira/browse/DERBY) in vain for this
>> particular error.
>>
>> Looking in the code where the error is reported in the source code, it
>> looks like it shouldn't happen. Could you post a JIRA bug report for
>> this error, please?  It you are able to make a stand-alone repro that
>> will increase your chances of having it fixed.
>
> After trying to boil this down and after much head-scratching, I've
> realised that I do the insert using a method in a DB utility class.
> There are two methods: dbInsert() and dbUpdate(). The difference is
> that doInsert() uses Statement.RETURN_GENERATED_KEYS when creating
> the prepared statement, and then calls stat.getGeneratedKeys() after
> the insertion.
>
> My problem seems to arise because I used doInsert to execute the insert
> even though there isn't a generated key. If I use dbUpdate() instead,
> the problem goes away.
>
> My attempt at a standalone repro tries to mimic this behaviour like so:
>
>   AUTOCOMMIT OFF;
>
>   INSERT INTO resources ...;
>   INSERT INTO resource_usage ...;
>   PREPARE p AS ...;
>   EXECUTE p USING ...;
>   VALUES IDENTITY_VAL_LOCAL();
>
>   COMMIT;
>
> but this works. So I suspect that IDENTITY_VAL_LOCAL is implemented
> differently, and the problem is due to Statement.RETURN_GENERATED_KEYS
> being used with a statement that doesn't generate a key.
>
> The stack trace I posted earlier began:
> java.sql.SQLException: Conglomerate could not be created.
>   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.executeUpdate(Unknown Source) 
>
>   at utils.DataManager.dbInsert(DataManager.java:1056)
>
> dbInsert lines 1056/1057 look like this:
>   stat.executeUpdate();
>   ResultSet r = stat.getGeneratedKeys();
> so the failure happens when the prepared statement is executed, just
> before the call to getGeneratedKeys().
>
> Does this suggest a cause for the "Conglomerate could not be created"
> error to anyone?

Hi John,

I believe your assumptions are correct.
This is a bug in Derby where the temporary row holder, used to hold 
generated keys, "overflows" and a temporary backing conglomerate is 
attempted created with a zero-length row template.

The bug can easily be reproduced using JDBC. Unless someone beats me to 
it, I'll log a JIRA and attach a regression test for the bug.


Regards,
-- 
Kristian

>
> TIA,

Mime
View raw message