Multiple production versions through WebLogic production redeployment

Lucas Jellema 1
0 0
Read Time:3 Minute, 43 Second

Production redeployment is a facility in WebLogic that provides the ability to temporarily have multiple versions of the same web application of web service active at the same time.

Sometimes, changes in application functionality require redeployment of the application. In the theoretical case of instantaneous responses from applications, we could argue that the roll out of a new version of an application is akin to the flip-of-the-switch: request A is handled by version X, the switch is flipped to bring version X+1 live and the next request B is taken care of by the new version. This, however, is not the reality. Requests take longer to process than no time at all. Besides, requests live in the context of a session – this applies to database as well as application server. This means that replacing version X with a new version X+1 in a throw-the-switch manner would not only potentially interrupt pending non-zero duration requests but would also – and far more harmfully – destroy all pending sessions. This would definitely not constitute zero-downtime application upgrade.

image

In order to not lose pending requests and sessions during application upgrades, there clearly is a need for the (temporary) co-existence of two versions of applications – the old one with potentially the pending conversations and the new one to deal with all newly initiated conversations.

Various products in Fusion Middleware have somewhat different ways of supporting this multi-version situation. This article looks at WebLogic for Web Services and Web applications (including ADF and WebCenter Portal applications).

WebLogic Server is used to deploy and run Web applications – such as ADF and WebCenter Portal applications – as well as Web Services. For all of these, WebLogic supports a mechanism called production redeployment. This too is a method for (temporary) multi-version support.

Suppose we have an Application called X. It has been deployed some time ago and is being used quite heavily. A new version of this application has been developed. If the application X has version information included – the WebLogic-Application-Version property in the file ApplicationRoot\meta-inf\MANIFEST.MF has been set – it qualifies for production redeployment. This means that when the new version of Application X is deployed as a redeployment of Application X, WebLogic ensures that for a limited period of time it will have both version 1 and version 2 of the application running, side by side. Version 2 is used for all new sessions. Version 1 is kept around for existing sessions. Only requests in the context of sessions that were created against version 1, before version 2 had been deployed, will be serviced by version 1. The old version is either kept around for a fixed period of time or until all sessions have been concluded. The next illustration shows the situation some time after the new version has been production redeployed: some new sessions have been created on version 2 and some pre-existing sessions are still connected to version 1.

clip_image002

In this scenario, none of the users suffers unavailability of the application. Either the user starts a new session on version 2 or the user’s session continues running on version 1. No planned downtime!

URL rewriting

Prolonged use of parallel multiple versions is not supported by WebLogic’s Production Redeployment feature: all new sessions will be initiated on the new version, if you like it or not. If you do not, there is another option – which requires a little more work on your part but offers more flexibility through the use of URL rewriting. For example using Apache HTTP server in front of WebLogic and then leveraging its mod_rewrite plugin, you can reroute requests for http://domain:port/application/path?someOptionalParameters to the version specific application URL such as http://domain:port/application_v2/path?someOptionalParameters.

clip_image002[5]

The actual rewrite logic is written in instructions in a configuration file. When the file is changed, the modifications are automatically reloaded so a server restart is not required. Note: the rewrite instructions can be quite sophisticated, for example looking at the client from which the request originates in order to determine to which URL to forward the request and checking whether the request is one initiating or continuing a session.

Resources

Production Redeployment , WebLogic Versioning by JaySenSharma on Middleware Magic blog – http://middlewaremagic.com/weblogic/?p=394

Introduction to URL Rewriting with Apache MOD_REWRITE – blog article by Ross Shannon – http://www.yourhtmlsource.com/sitemanagement/urlrewriting.html

About Post Author

Lucas Jellema

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director and Oracle Developer Champion. Solution architect and developer on diverse areas including SQL, JavaScript, Kubernetes & Docker, Machine Learning, Java, SOA and microservices, events in various shapes and forms and many other things. Author of the Oracle Press book Oracle SOA Suite 12c Handbook. Frequent presenter on user groups and community events and conferences such as JavaOne, Oracle Code, CodeOne, NLJUG JFall and Oracle OpenWorld.
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

One thought on “Multiple production versions through WebLogic production redeployment

  1. Hi Lucas

    One other comment on WLS production redeployment is it is incompatible with WLS shared libraries. As per the the Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server 10.3.5 guide, section Using Partial Redeployment for J2EE Module Updates subheading “Restrictions for Updating J2EE Modules in an EAR”:

    If redeploying a single J2EE module in an Enterprise application would affect other J2EE modules loaded in the same classloader, weblogic.Deployer requires that you explicitly redeploy all of the affected modules. If you attempt to use partial redeployment with only a subset of the affected J2EE modules, weblogic.Deployer displays the error:

    Exception:weblogic.management.ApplicationException: [J2EE:160076] You must include all of [module_list] in your files list to modify [module]

    Regards,

    CM.

Comments are closed.

Next Post

Reduce occurrence of ORA-04068 while upgrading PL/SQL packages by moving global variables to Application Context

This article will argue against the use of (stateful) global PL/SQL variables – as they are both a potential problem for stateless web applications and the availability experienced by end users during database upgrades. In various database releases, Oracle did a lot of work in supporting online redefinition of database […]
%d bloggers like this: