5 Replies Latest reply on Aug 29, 2009 9:27 PM by 719960

    BEA WebLogic vs OAS/OC4J: application redeployment

    Chris Muir-Oracle
      Hi gang

      I'm currently researching solutions to JEE application redeployment, or more specifically when you want to update an existing deployed application on a JEE app server, how can you do so with minimal interruption to the users?

      From my research on the internet I've found two approaches, one with the Oracle OAS camp, and another in the BEA Weblogic camp.

      Deepek Arora in this Redeploy Web App to Application Server points to an Oracle whitepaper that states the OAS approach is to use clusters. However this article is somewhat old so may not be the most recent recommended approach.

      I note that in the BEA documentation for the WebLogic Server here, the documentation details a feature called Production Redeployment (documented here). This feature allows both versions of the application to be deployed, and gracefully moves new user connections to the new application version, while maintaining existing user connections on the old version, eventually shutting down the older application version once the users have disconnected.

      What I'd like to know and I hope you can help me with is:

      a) Is clusters still the recommended OAS approach to this problem?
      b) Does OAS support the similar WebLogic facilities, or are there plans in the future (maybe 11g?) to include this feature?

      Very much thanks for your assistance in advance. This question has been bugging me for awhile, so it'd be great to hear your thoughts and recommendations. Alternatively any pointers to any Oracle documentation, whitepapers etc would be appreciated as there is a lot to digest.

      Thanks & regards,

      Chris Muir.
        • 1. Re: BEA WebLogic vs OAS/OC4J: application redeployment
          Steve Button-Oracle
          Hey Chris --

          OC4J doesn't implement the same side-by-side versioning approach that WLS does -- it's a nice facility from what I have seen of it. We should buy them if we ever get the chance .. :-) Their staged/admin-only deployment model is also very useful for deploy/test/publish scenarios.

          In OracleAS 10.1.3.1+ we have the ability to execute a redeployment operation to a "group" of OC4J instances in a serial form.

          When a sequential redeployment operation is executed, the cluster deployment handler:

          1. Picks the first OC4J instance in the group.

          1.1 The container STOPS the application
          1.1.1 Signals to mod_oc4j to take it out of the route table so it doesn't get any new requests -- this happens dynamically with no restart required with OHS/mod_oc4j 10.1.3.
          1.1.2 Allows all current inflight requests to finish, flushes any session state updates

          1.2 The current version of the application is then undeployed

          1.3 The new version of the application is deployed

          1.4 The application is started
          1.4.1 Signals to mod_oc4j that is available for service, dynamically added back into the routing mix.

          1.5 Starts receiving and servicing requests

          2. Group deployment mechanism waits for the specified timeout period.

          3. Repeats the process for the remaining OC4J instances.

          4. Finishes.

          Since we have session affinity with OHS/mod_oc4j routing, any existing client requests will continue to go to their current instance unless it is stopped. So for customers on V1 of an application, they'll stay on it until it is upgraded. Any requests that get serviced by V2 of an application will continue to be serviced by that server/application, unless it is taken down for some reason.

          For those applications that are maintaining client "state" within the server, if the application has configured state-replication, then any session state will be maintained on other nodes as the redeployment of a specific node occurs.

          In earlier releases, this was documented in a far more manual fashion as something called a "cluster dance" -- where due to the automated synchronization when operating in a cluster, you needed to take instances out of one cluster into another to do the upgrade, then join them back together.

          http://www.oracle.com/technology/products/ias/hi_av/OracleApplicationServer10gR2StatefulRollingUpgrades-WP.pdf

          The sequential group deployment mechanism, IMHO offers a much simpler path to do a multiple instance redeployment while maintaining availability.

          There's a general doc about this from the same author above here:

          http://www.oracle.com/technology/products/ias/hi_av/OracleApplicationServer10gR3HA-WP.pdf

          There's a screen cam/viewlet somewhere on OTN I believe that demos this as well.

          And a fairly simple form of how-to here which walks you through an example:

          http://www.oracle.com/technology/products/ias/hi_av/Dynamic%20Routing.htm

          -steve-
          • 2. Re: BEA WebLogic vs OAS/OC4J: application redeployment
            Chris Muir-Oracle
            Thanks for your reply Steve. Do you mind if I post a link to this discussion on my blog? I think a few people will find the discussion interesting.

            CM.
            • 5. Re: BEA WebLogic vs OAS/OC4J: application redeployment
              719960
              "Since we have session affinity with OHS/mod_oc4j routing, any existing client requests will continue to go to their current instance unless it is stopped. So for customers on V1 of an application, they'll stay on it until it is upgraded. Any requests that get serviced by V2 of an application will continue to be serviced by that server/application, unless it is taken down for some reason."

              We have our application deployed to a 2-node cluster of OAS 10.1.3.3.0. I have setup OHS with 'roundrobin-local affinity'. There's only 1 JVM per node but the setting stops cross-node chatter. My question is, if a subsequent request in a session went to the wrong OHS, would it still be redirected correctly? If it helps, these are RPC calls from a GXT/GWT client?