db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: Error when executing query:com.ibm.websphere.ce.cm.StaleConnectionException: Meta-data for Container org.apache.derby.impl.store.raw.data.RAFContainer@6fd148fc could not be accessed
Date Thu, 30 Nov 2006 00:50:31 GMT
Suraj Batuwana wrote:
> createDB.sql in the attached zip file has all the sqls for database tables,
> indexes and views
> Error comes when run SELECT * FROM
> vwDerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178
> Can use the CreateDatabase.bat to create the derby database and
> TestIssue.bat can use to test the issue.
> derby.log has the error I am getting.
> Above was tested with derby but get the same results
> Please let me know if any one of you able to reproduce the issue

Suraj ,

Thanks a lot for providing scripts to reproduce the error. I am able 
to reproduce the problem you are seeing on jdk14 and jdk13. Query work 
s fine on jdk15. As I mentioned earlier , I think this error is 
happening because too many files are kept open(> 2000).  On jdk14 ,you 
are hitting the jvm bug. 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4189011, that cause 
the above error, when a container file opens.

Now the obvious question is why derby is keeping so many files open to 
compile the query ?

view "vwDerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178"  is 
pretty huge and uses other views. Total of no of user
tables are 1197, and there are 2301 index containers. This query
opened 2078 container files when I ran on jdk15. I could not find any 
cases in rawstore where files are not getting closed correctly.

By doing quick scan of the code,  I think during the query 
optimization Derby opens all the tables and all the indexes on each 
table to estimate the costs and those containers are not closed until 
the nested transaction used to compile the query is closed. Because 
the containers used to estimate the cost are not closed, 
corresponding  container files can not be closed, so the container 
cache (file handle cache ) keep growing.  May be it is
not really required to keep all containers open until the end of 
compiling the query. Optimizer gurus , please correct me if I am
saying something that is incorrect here.


View raw message