1

We have a stand-alone single user desktop application that has a Swing front-end and uses an embedded Derby database (10.8.2.2 1181258). Spring (3.0.4) is used as the go between the application and the database. A customer (in Hebrew/Israel locale iw_IL) running the application using JRE 1.7.0_21 ran into an issue. The following stack trace was logged: 

ERROR [index-stat-thread] stderr - Exception in thread "index-stat-thread"    
ERROR [index-stat-thread] stderr - java.lang.ClassCastException: org.apache.derby.impl.store.access.btree.BranchControlRow cannot be cast to org.apache.derby.impl.store.access.btree.LeafControlRow    
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.store.access.btree.BTreeScan.positionAtNextPage(Unknown Source)  
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(Unknown Source)  
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(Unknown Source)  
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl$KeyComparator.fetchRows(Unknown Source)  
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.updateIndexStatsMinion(Unknown Source)  
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.generateStatistics(Unknown Source)  
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.processingLoop(Unknown Source)  
ERROR [index-stat-thread] stderr -  at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.run(Unknown Source)  
ERROR [index-stat-thread] stderr -  at java.lang.Thread.run(Thread.java:722)

Any idea what might cause such an error?

Subsequently, Spring logged the following:

org.springframework.jdbc.support.SQLErrorCodesFactory - Error while extracting database product name - falling back to empty error codes  
org.springframework.jdbc.support.MetaDataAccessException: Could not get Connection for extracting meta data; nested exception is org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLNonTransientConnectionException: No current connection.  
    at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:293)  
    at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320)  
    at org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:212)  
    at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141)  
    at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.<init>(SQLErrorCodeSQLExceptionTranslator.java:104)  
    at org.springframework.jdbc.support.JdbcAccessor.getExceptionTranslator(JdbcAccessor.java:99)  
    at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:602)  
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:636)  
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:665)  
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:673)  
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:713)  
    at org.springframework.jdbc.core.JdbcTemplate.queryForList(JdbcTemplate.java:796)  
    at org.springframework.jdbc.core.simple.SimpleJdbcTemplate.queryForList(SimpleJdbcTemplate.java:235)

Given that the application uses an embedded Derby database on the same machine and file system as the application, the JDBC connection error is baffling. Could the first Derby error be the reason for this?
Following this is another error from Spring while loading entries for one table, which essentially seems to be the same as the first error from Derby:

ERROR [main] org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL [select * from XYZ where scresult_id=?]; SQL state [XJ001]; error code [0]; Java exception:   
'org.apache.derby.impl.store.access.btree.BranchControlRow cannot be cast to org.apache.derby.impl.store.access.btree.LeafControlRow: java.lang.ClassCastException'.;   nested exception is java.sql.SQLException: Java exception: 
'org.apache.derby.impl.store.access.btree.BranchControlRow cannot be cast to org.apache.derby.impl.store.access.btree.LeafControlRow: java.lang.ClassCastException'.

The same application has been used successfully by other customers for several months. This is the first time a customer has run into these problems.

Improve this question

1 Answer 1

Reset to default
1

It looks like your database has become corrupt. Those are internal messages that you should never see.

Here is information about how to use your backups and logs to recover your database: http://db.apache.org/derby/docs/10.10/adminguide/cadminhubbkup98797.html

Before you restore the database, you should retain a copy of the damaged database, the derby.log file, and any other information about the circumstances under which the database became corrupt, as they may give you important clues about how to prevent this problem in the future.

In general, it should not be possible to corrupt a Derby database like this; hence arriving at such a situation might indicate a bug in Derby itself. But there could be other possible explanations, such as damaged or misconfigured hardware.

I assume from your initial question that you do not know how to reproduce this problem? In that case, preserving as much information as you can about the incident, and about what was occurring at the moment that the corruption occurred (did the power fail? Was the machine hard-rebooted? did a disk become full? was a virus-checker running on the machine? There are a million possible questions like this to ask...) may give you clues about how to reproduce the problem yourself.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thank you Bryan for a prompt response and the helpful hints. You were correct in assuming that we didn't know how to recreate the problem. We too suspected database corruption, but didn't know if there is known problem that causes it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.