You would override the OnInit method in your business service, it's what is called when a business host starts up when a production comes up (assuming it was enabled when the production went down)

You can even set a call interval so that it does that X amount of seconds / minutes / hours. 

Also, Ens.Director is not a business host class that you can use, it's a class that allows you to control various features of a production as well as monitor its state.

You may to look into using the DSTIME feature that cache offers, we use it for our BI tools to grab the most recent data.

I would recommend the DSTIME approach as well. We use this for syncing up information from our cache ERP to our BI tool. DeepSea is actually using DSTIME to show changes as well. 

With using DSTIME you are allowed to write code and determine what DSTime batches you want to synchronize with, allowing you to fully control how often you want to sync up data. 

This is probably an aggressive approach but you could try and do the following:

• Create a code database with your class marked with final in it
• Deploy said code with class marked as final and mount code as read only
• Map the read only code database to the namespace that needs to access it

This should prevent a developer from being able to inherit from the class while still being able to access it. This is also an assumption that the meta data of class definition is included in the read only database. If it isn't, that's a very interesting flaw of what a read only code database means. 

Kevin,

We have the following solution when having the code and data dats separated. We would have a CODE1 dat and a CODE2 dat. Which ever code dat wasn't being used by the namespace, we would overwrite that file and then switch the namespace to point to the new code database. Keeps our deployment downtime to only a few milliseconds. 

The only situation we've run into is this doesn't seem to be ideal for ensemble without having to stop the ensemble production.

John,

We have entertained the idea of doing this and probably will be soon, but we always push our code CACHE.DAT to both the primary and secondary servers and then switch our namespace to use the new DAT files. While it becomes more cumbersome with additional servers, for now it has been an easy approach with minimal downtime. 

Maybe I'm missing something but with the way we have our code and data split our, we're only mirroring our data. So an advantage of using the System Default Settings is the change made on the primary is already updated on the secondary. Is there a best practice on this type of setup when dealing with having to fail over to a secondary and needing the existing business host values the same? I do agree that it would be nice if we could use the Sytem Default Settings to be available to multiple namespaces.