Critical Hotfixes

The latest important information about critical issues that could affect your JADE environment.

PAR 68312 - SDS Reorg Replay Issue

16 June 2021 - Reorg replay became sensitive to variations  in database configuration

 

Issue is addressed by 16.0.02.050, 18.0.01.099 & 20.0.01.047 hotfixes

What is the problem?

Changes to file extent management introduced with hotfixes: 16.0.02.046, 18.0.01.092 & 20.0.01.038 result in logical file extents being allocated according to configuration information associated with a database; specifically, the PersistentDb.DefFileGrowthIncrement INI setting or in the extentSize attribute set using dbutil for each database file, rather than a fixed value. 

A consequence of these changes is that the replay of file reorgs on SDS secondary database became sensitive to file extent size configuration. When a file reorg is replayed on a secondary database and the file (for any reason) has different extent size values to those on the primary database, the reorged file on the secondary will diverge in structure from the reorged file on the primary. Structural divergence will cause failures replaying subsequent journaled updates to the reorged file on the secondary database.

The problem could also occur when hotfixes 16.0.02.046, 18.0.01.092 & 20.0.01.038 (or higher) were installed on the primary database but not the secondary (or vice versa).

What is the solution?

Install the hotfix, 16.0.02.050 18.0.01.099 or 20.0.01.047 

The issue has been resolved by ensuring file reorgs use an invariant extent size to remove sensitivity to variations in primary versus secondary configuration.  

Notes:
1) It is important to ensure that when you install any of these hotfixes (or higher versions) on a primary database you also install it on secondary database before the secondary is required to replay a reorg executed on the primary.  

To check this has been done, a sdsUpgradeVersionCheck audit record is journalled on the primary prior to the execution of a replayable reorg. When the version check audit record is replayed by a secondary database, tracking will halt if (and only if) the minimum level hotfix is not installed.  

The following messages will be logged.
2021/06/09 17:14:08.262 09618-0214 SDS: Secondary upgrade version mismatch: tracking will now halt
2021/06/09 17:14:08.267 09618-0214 SDS: Upgrade to the same software release level as the primary and restart server

2) There is no check to detect the scenario where this hotfix is installed on the secondary and not the primary.

3) We strongly recommend you take an online backup after the hotfixes have been installed so that you can safely execute a roll forward recovery through a replayable reorg with a single consistent set of code files.

PAR 68271 - Persistent Array entries overwritten in JADE 2020

17 May 2021 - Persistent Array entries overwritten

 

Issue is addressed by the 20.0.01.043 hotfix

What is the problem?

In JADE 2020, under certain situations existing entries in an array with variable membership type (Binary, String, or StringUtf8) are overwritten with null when an entry is added or inserted. This can happen to persistent arrays that are upgraded from 2018 if the array membership is variable type. Whether this error occurs is dependent on the maximum length of the array membership type and the population of the array in 2018. The number and length of the initial values and number and length of values added to the array in 2020 are also relevant.

What is the solution?

Install the hotfix 20.0.01.043. Ensure all systems upgraded to JADE 2020 are upgraded to at least hotfix 20.0.01.043.

PAR 68158 and 68240 - Critical Database Issue

5 May 2021 - Database File Corruption

 

Issue is addressed by 16.0.02.048, 18.0.01.096 & 20.0.01.040 hotfixes
Note: These hotfixes supercede: 16.0.02.046, 18.0.01.092 & 20.0.01.038.

What problems do these hotfixes address?

1) A background flush of blocks recently appended to the end of a file could overlap with physical file extension during a database checkpoint. When the overlap occurred, there was a timing window that under some conditions could result in file truncation and data loss.
 
While it is considered a very rare scenario that the issue occur, we advise all users to install the relevant hotfix ASAP.
 
2) Prior to a recent hotfix, the extentSize attribute was only used to control physical file extension. Now it is also used to control the size of logical extents. JADE releases since 5.2.8 have not allowed the control file value to be set smaller than 64K, but legacy values have been carried through release upgrades without being checked or corrected.
 
To handle the legacy values that may be present in user databases that began their life prior to 5.2.8, the database engine now detects and automatically corrects invalid values. When invalid values below the current 64K minimum are detected, a warning is logged in the jommsg log and the control file value is set to zero. A zero value is interpreted to mean use the INI configured value for DefFileGrowthIncrement (default = 128K, minimum = 64K).

What is the solution?

Install the hotfix: 16.0.02.048, 18.0.01.096 & 20.0.01.040

PAR 68158 - Critical Database Issue

15 April 2021 - Database File Corruption

 

Issue is addressed by 16.0.02.046, 18.0.01.092 & 20.0.01.038 hotfixes

What is the problem?

A background flush of blocks recently appended to the end of a file could overlap with the physical file extension during a database checkpoint.
When the overlap occurred, there was a timing window that under some conditions could result in file truncation and data loss.

While it is considered a rare scenario that the issue occurs, we advise all users to install the relevant hotfix as soon as possible.

What is the solution?

Install the hotfix, 16.0.02.046 18.0.01.092 or 20.0.01.038

PAR 67915 - .NET Import Issue in JADE 2018 and 2020

18 December 2020

 

Issue is addressed by 18.0.01.085 & 20.0.01.020 hotfixes
Note: The initial hotfixes 18.0.01.084 and 20.0.01.018 were withdrawn and replaced by these two.

What is the problem?

With the release of JADE 18.0.01, the .NET external component library wizard was updated to support two new type conversions.

  • DateTimeOffset .NET type now maps to TimeStampOffset JADE type
  • Byte[] .NET type now maps to Binary JADE type

Both of these types previously mapped to JadeDotNetType in earlier releases.
Hotfix 18.0.01.074 was later released, as it was found the new Binary type conversions were not working.

It has now come to our attention that as of hotfix 18.0.01.074 (including 20.0.01), any assemblies that were imported with the previous mapping (Byte[] to JadeDotNetType) can cause exceptions if attempting to access properties or methods with these types.

What is the solution?

To ensure backwards compatibility while also supporting these new mappings, we are releasing a new hotfix in JADE 18.0.01.085 and 20.0.01.020 that supports both the old and new type mappings. Any assemblies imported prior to JADE 18.0.01 will continue to function as expected after applying this hotfix.

However, as this was not introduced with the initial release of 18.0.01, it may require a fix-up script to be run to correct the generated JadeDotNetType methods and compatibility flags.

Who needs to run the fix-up script?

Any JADE 18.0.01 or 20.0.01 systems that have had .NET assemblies imported/re-imported in either release AND have imported either of the following:

  • Imported .NET classes with properties, fields, method/event parameters/return values of the type DateTimeOffset
  • Imported .NET classes with properties, fields, method/event parameters/return values of the type Byte[]

    The fix-up method `RootSchema::Schema::_fixDotNetImportMethodsAndSetFlags` will need to be executed once after applying the hotfix if the system meets the above criteria. This script will modify and recompile the necessary generated methods for affected assemblies, as well as set some compatibility flags on the generated assembly meta data.

    We have also provided another method `RootSchema::Schema::_fixDotNetImportCompatibilityFlags` that will just perform setting the compatibility flags. This method should be used if the method changes are deployed to the system.

    Alternatively, any imported .NET assemblies that meet the above criteria can be re-imported after applying the hotfix. This will cause the methods to be generated correctly and compatibility flags to be set.

    The following is an exmaple of running the fix-up method via command line:

> jadclient path=database-path ini=initialization-file-name app=RootSchemaApp schema=RootSchema executeSchema=RootSchema executeClass=Schema executeMethod=_fixDotNetImportMethodsAndSetFlags

 

Help-Icon-01

Need help?

If you have hit a snag in your download or install we recommend:

We offer different support options depending on your needs and platform usage; take a look at the Support page for more details.

Visit Support