LDN - Luminis Developer Network

This information provided here for archival and documentation purposes

The answer as to whether Luminis IV could recover from a database restart was 'sort-of', with conflicting responses. It ended up as defect #1-3J67MJ, now resolved. The resolution appears in the documentation for the IV.1.0 upgrade.

Here's a summary of what I found out myself and from the RC:

• Attempts to recover from a database restart are controlled by a configman entry: ...validateconnections (see IV.1.0 release guide page 23 for full name) 'true' means attempt to re-connect, 'false' means don't try.
• If this entry is missing, it defaults to 'true'.
• This entry is missing in IV.0.0 and IV.0.1 (and hence, true)
• This entry is added in IV.0.2 with value of 'false'.
• There is no documentation for the change in IV.0.2. Most RC support engineers did not know either.
• As of IV.1.0, information on this topic is included in the Release Guide and the default now seems to be : 'Luminis Platform cannot recover when the backend RDB has been stopped and restarted'. However, information on how to override this behaviour is given (validateconnections=true) with a warning that this could lead to performance issues.
• This change in recommended setup may be related to the fact that some institutions host their Luminis and uPortal database tables in different database instances. Enabling recovery will only re-establish a connection to the uPortal database, not the Luminis database (Message Board, TAs, Group Tools).

So, to summarize:

• Reconnects work on IV.0.0 and IV.0.1 (and probably III) because there is no validateconnections entry.
• Reconnects do not work on IV.0.2 and higher because validateconnections=false is added as part of this upgrade.
• Modifying configman to validateconnections=true returns all Luminis IV versions to pre-IV.0.2 behaviour.
• Note that unpatching from IV.0.2 to IV.0.1 results in reconnects *not working* on IV.0.1 as this entry is not removed from configman during the unpatch.

Bob.