db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-3347) ERROR XSDB3: Container information cannot change once written
Date Mon, 14 Apr 2008 18:43:49 GMT
It is obviously not very quick but a simple utility routine could
be called which could create a new table, insert enough data that
would then flush every existing page from the cache and it's size which
I don't know if it is program gettable but could at least be hard
coded to default.  This routine
of course would depend on the behaviour of the cache in question.  So
if it got smarter to avoid a table scan or a table load from flooding
the cache and bumping everything then it would not work.

I personally would find such an internal testing interface useful, but
do wish there was easy way to make it available to our tests but not
to general user usage.


Knut Anders Hatlen wrote:
> Bryan Pendleton <bpendleton@amberpoint.com> writes:
>> Mike Matrigali (JIRA) wrote:
>>> affects  page 0, which happens to be accessed a lot and thus is in
>>> cache a lot.   
>> Perhaps it would be helpful to add a special internal testing API
>> which enables test programs to discard the cache at interesting moments?
>> I know special testing hooks are gross, but sometimes they can also be
>> really helpful for enabling better testing.
> It shouldn't be too difficult to implement, I think. The CacheManager
> interface already has the needed functionality through these methods:
>   - ageOut() - removes all clean objects that are not held
>   - discard() - same as ageOut(), but also removes dirty objects
>     (without cleaning them)
> For the statement cache, ageOut() is exposed to the users via the stored
> procedure SYSCS_UTIL.SYSCS_EMPTY_STATEMENT_CACHE(). We could probably do
> something similar for the page cache and the container cache.

View raw message