When to use Package upgrade and when to use DLL upgrade in JIT deployment
|Product/Release:||LANSA for Windows|
|Abstract:||Considerations behind using a Package or a DLL JIT Package upgrade.|
|Submitted By:||LANSA Technical Support|
LANSA provides two types of JIT Package deployment, DLL Upgrade and Package Upgrade. There are scenarios where a DLL Upgrade is the most efficient and suitable deployment model and there are scenarios where a Package upgrade is more suitable. The following considerations should be kept in mind when deciding on your JIT deployment model.
You would use a DLL Upgrade Model when:
- You have deployed a small application and now you want to update this application with minimal DLL additions or DLL changes.
- You have deployed a large application but each end user only uses a small part of the application and therefore would only need the few DLL additions or changes that directly affect them.
You would use a Package Upgrade Model when:
- You have a large application. (the definition of what is "large" is depends on the download time. Over a dial up it might be a small number of DLLs, on a 1 gigabit LAN, where download times would be greatly reduced, a huge number of DLLs could make up the "large" application)
- You have an application that has a client database.
- You have non-LANSA objects to upgrade
- You have file definitions to upgrade (a DLL upgrade cannot upgrade the CTD file, etc.)
- You limit access to parts of the Application by not allowing a user to install them
- You want to have a version control strategy. In this model, you can control whether Package B needs Package A to exist before it can be deployed. Or you can control that Package C is optional until Package D is distributed at which point it becomes mandatory, etc.
- In a model where you have a "Home Base" Application Server and many Regional Application Servers to their Client end users. In this situation the Regional Servers become a client to the "Home Base" Application Server ie. all the package upgrades are deployed to the "Home Base" Application Server and when the end user Clients connect to the Regional Application Servers for an upgrade, the Regional Application Servers connect to the "Home Base" Application Server for the upgrade. (In this model the Regional Application Servers would have the Install parameter set to No ie. INST=No).
- you want to automatically ship EPCs and upgrades to the LANSA runtime environment. These updates are only downloaded if the client does not already have them.
Other things to consider when choosing a JIT deployment model:
- Package upgrade is the recommended model in most JIT upgrade situations.
- DLL Upgrade is very limited in that it can upgrade application programs only ie. you cannot update a file definition or a non-LANSA object etc. It is best suited to updating SuperServer clients.
- Package upgrade is much faster during the checking phase because instead of having to check through every DLL on the Application Server, it only needs to check 1 file on the Application Server for the existence of a new Package. However, it should be kept in mind that only the checking time is greatly reduced, the actual time to download the required objects is always dependent on their size. But given that the checking occurs EVERY time the Application starts up, it is a very significant issue.
- For better performance of very large package or DLL upgrades, an overnight batch job that performs the upgrade should be considered rather than performing the checking/upgrading during application startup.