Dynamic packages in a multi-threaded application 1

[Griffyn]

Hi all,

I've written a service application that provides a HTTP server. It uses a database driven menu system to provide different webpages (system management stuff). I've written the first few functions and all is ok. Now I want to deploy for many people to be able to use, but also continue development on new functions without interrupting anyone who may be using the existing functions - at the moment, I'll need to stop the service, copy across the updated .exe and restart the service.

It occurred to me that I could use dynamic packages - when a function is used, it loads the package, and unloads when done. Adding new packages or modifying existing packages should be as easy as a copy/paste of the .BPL file, and no stop/restart of the service application is required.

Before I embark on this approach, I've realised that this is a multi-threaded environment - the package load/unloads will occur during one of the TIdHTTPServer context threads. So if two people are trying to use the same function, it would try to load the same package twice. I've googled for information on whether this is allowed or not, and can't find anything.

Do I need to manage the package loading/unloading outside of the TIdHTTPServer thread context? Or can the same package be loaded multiple times? Or should I be staying away from this type of thing altogether for this project?

Your thoughts and experience are much appreciated.

Thanks,

Griffyn

 

[DjangMan]

This product might help you (or at least inspire you). I haven't used it but I'm tempted by it often.

http://www.dragonsoft.us/products_dsps.php

You might consider not using constant load/reload cycles but use their method of telling the system to unload a module and then reload it when you've completed your installation.

Another challenge of loading/unloading on the fly is what happens if you want to post an update and users are trying to load that part of the framework? Using the idea of managing the process of taking down part of the framework for maintenance is appealing in this case.

 

[Griffyn]

I like the 'update' approach better. Dynamically load all packages, have a timer event monitor for package updates, use a TMREWSync object to lock out any threads, unload package, copy in new update, load package.

Thanks for the idea

 

[Griffyn]

Confirmation if anyone is interested - this has been implemented, and is working really well. The downsides of working with packages is that I had to enable the Build with Runtime packages option for the project. Which means I had to identify and deploy a whole bunch (about 15) of other .BPL files with the .exe

At one point, I considered swapping over to using DLLs, which I've used in the past, but these don't play nice with classes (instantiating classes declared in the DLL seems tricky and would need to have interfaces for the classes at the least).