db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@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 Fri, 01 Dec 2006 22:18:30 GMT
Suresh Thalamati wrote:
> 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.  

I'm not very familiar with the costing mechanism of the optimizer (most of the 
work I've done just assumes that the costs are correct), but I spent some time 
looking at the cost estimation code and I agree with Suresh: as far as I can 
tell, it looks like the optimizer opens the containers for base tables and 
indexes in the query but does not close them until compilation completes.

> May be it is not really required to keep all containers open 
> until the end of compiling the query.

It may be possible to add logic that closes and re-opens the containers during 
optimization as they are needed.  Note, though, that the containers are 
deliberately cached in the current code and the assumption appears to be that 
they will remain open throughout optimization.  So I think any changes in this 
area could be non-trivial and would have to take into consideration potential 
performance effects.  But that said, I willingly admit that I know very little 
about the relevant parts of the Derby code, so I could be wrong.

In any event, maybe the best thing to do here is to file a Jira enhancement for 
tracking purposes?  If you (Suraj) choose to do so, the zip file containing the 
reproduction could be attached to the Jira issue for ease of reference.

 > But now the big problem is my application does not support jdk15. Is
 > there a way we can have a fix for the above issue with using the jdk14 ?

The first step toward resolving the problem is to file a Jira issue:


Once that's done, the easiest way to get a fix into the codeline is to 
contribute the changes yourself :)  If you have the time and inclination to work 
on this issue, you should feel free to join the community:


Otherwise you can just file the Jira issue and then anyone who is interested can 
pick it up and work to resolve it...


View raw message