db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suraj Batuwana <sbatuw...@virtusa.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 Tue, 05 Dec 2006 07:23:53 GMT

I have file a JIRA issue at 
https://issues.apache.org/jira/browse/DERBY-2144


Army-4 wrote:
> 
> 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:
> 
>    http://db.apache.org/derby/DerbyBugGuidelines.html
> 
> 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:
> 
>    http://wiki.apache.org/db-derby/DerbyDev
> 
> Otherwise you can just file the Jira issue and then anyone who is
> interested can 
> pick it up and work to resolve it...
> 
> Army
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Error-when-executing-query%3Acom.ibm.websphere.ce.cm.StaleConnectionException%3A-Meta-data-for-Container-org.apache.derby.impl.store.raw.data.RAFContainer%406fd148fc-could-not-be-accessed-tf2634449.html#a7694568
Sent from the Apache Derby Users mailing list archive at Nabble.com.


Mime
View raw message