db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: [PATCH] upgrade fix related to checksum support for transaction log to recognize out of order log writes during recovery (Derby-96)
Date Sat, 23 Apr 2005 19:13:40 GMT

Attached is the  new  patch  with the suggested changes to make 
softupgrade correctly with the  transaction log
checksum feature in 10.1 Added  checkVersion() method  to log factory it 
self,  becuase that is where
the  version numbers are read  from  from the log control file , but did 
not export the call it to  the
rawstore factory  as it is not needed now.  (This can be done easlily 
when there is a  need for upgrade
checks  in the other store modules..)


Mike Matrigali wrote:

> Ok, that is the info I needed.  Suresh could you resubmit the change
> with comments like the one dan has below.  And change the check to
> simply check if the on disk version is is 10.0, no need to check
> current version.
> It would be nice to have some sort of store facility like the one
> language has, but the problem for this case is that logging system
> needs it during boot and there is not much else available until boot
> is finished.
> Daniel John Debrunner wrote:
>> Mike Matrigali wrote:
>>> Given that Dan is working on the upgrade stuff, I think the change 
>>> below
>>> handles the current, and next release fine.  More changes can be made
>>> as it becomes clear how rest of code is handling soft upgrade.
>>> Going forward I would like to see a better model for the code below. 
>>> For
>>> this discussion assume current release is 10.0.x and next 2 releases
>>> are 10.1.x and 10.2.x.  If derby supports soft upgrade from 10.0.x
>>> directly to 10.2.x then the code below will have to change, meaning
>>> someone is going to have to remember to change it (maybe a sanity
>>> statement could force an error if version is not what is expected?):
>> Soft upgrade is expected to work on any previous release, and the code
>> to handle it should work without having to change every release.
>> Take a language feature that was added in release X and cannot be used
>> in soft upgrade mode because it writes new information to the system
>> catalogs, that would not be understood by releases earlier than X.
>> The language layer handles this by checking that the database (on disk)
>> has been upgraded to at least release X before allowing compilation or
>> execution of the feature, by calling the method
>> DataDictionary.checkVersion().
>> E.g. for a routine with a method signature (new in 10.1) this check is
>> made (I'm just about to commit this code).
>> // Support for Java signatures in Derby was added in 10.1
>> // Check to see the catalogs have been upgraded to 10.1 before
>> // accepting such a method name for a routine. Otherwise
>> // a routine that works in 10.1 soft upgrade mode would
>> // exist when running 10.0 but not resolve to anything.
>> if (this.methodName.indexOf('(') != -1)
>> {
>>   getDataDictionary().checkVersion(
>>      DataDictionary.DD_VERSION_DERBY_10_1,
>>                "EXTERNAL NAME 'class.method(<signature>)'");
>> }
>> This style of check will work with any future version so it's a safe
>> approach.
>> The store layer needs to have a similar policy.
>> Dan.

View raw message