Question Pass Signal Across Sessions In Progress?

[catch.saravana]

Is it possible to pass value across sessions in Progress without using DB/File? Say we have a scenario (not the actual scenario, sorry about that) where once we switch a server (may be a messaging server) from one to another and in turn system now has to use couple of different configuration parameters which will have to be switched on the fly without requesting the users to logout and login. Do we have any inbuilt function or some other method where the moment the server is switched from a .p file have to send signal to all active sessions and they will in turn start to use the new set of parameters?

 

[ForEachInvoiceDelete]

You could make all your clients have a built in socket listener.

You can do this via progress and it does work.

 

[TomBascom]

It sounds like you want your application to automatically switch between a primary and secondary db if the primary fails and the secondary then becomes to new "source" db in an OE Replication (or even a "log shipping") scenario. Is that correct?

You can do this by trapping the STOP condition in your application startup routine. Basically you need an ON STOP wrapper and some logic that determines which database to connect to. You can fiddle with the startup parameters in the CONNECT statement. This will avoid OS level logins and so forth but it is basically restarting the application -- if the user is somewhere deep within the context of the app they will be brought all the way back to the startup procedure. Depending on how you maintain context that might be a problem. Or not.

 

[catch.saravana]

@TomBascom - sorry for not providing the scenario. Let me give the scenario, there was a scenario that came up in our last meeting saying let's have one prod DB on a server which will be active and one more db on another server which will be acting as a backup (we will be replicating the data using OE replication and make sure both are in sync). We have a bi-weekly deployment and for every deployment we were thinking of switching servers without any down time (our application runs 24/7 and currently we have a downtime of 1 hour). This discussion was all about if we could do this without any downtime. In our scenario we were planning to do the deployment on the backup server and make it active and vice versa for the next deployment. Is that possible? Is it advisable?

so in this case if you see we have to switch servers and make the users not to logout and login. Or as we are switching is it good to make them logout and login back?

 

[ForEachInvoiceDelete]

You could add a socket server element to all your clients, with a procedure called "DcandRc".

When you want to perform the switch you would have a disconnect and connect statement in the client to switch the database. and a "client" procedure on a seperate machine in a repeat loop sending the socket connect message through a temp-table of IP addresses.

Progress KB - Sample 4GL Socket Programming Code for Client Side <--- You'd be running a modified version of this on a seperate machine

Progress KB - Sample 4GL Socket Programming Code for Server Side <--- And you would build this into your application.

disclaimer :- This probably isn't the most efficient way to do what you want, or the most elegant way. I just know it would meet the requirements.

 

[TomBascom]

I think you're gilding the lily before you've shown that you have a viable strategy to manage even basic redundancy.

If a "deployment" involves applying DF files then:

1) there is almost never a need for down time. almost all df files are new objects. and those can be applied online. with replication in the mix and a large database you might need to be careful about anything that builds an index but otherwise it is fairly simple and straight-forward.

2) if you do NOT apply the DF to the source and allow replication to propagate the changes then you are going to have to re-seed replication -- with a large database that is very painful and even more so if they are not in the same data center.

If a deployment is code-only then you could do it as you say -- first deploy code to the secondary and then switch. BUT you will still need to disconnect and reconnect users and that raises all of the questions about context. If I recall your other posts you have an old v9 application that you are migrating to 11.6 -- if that is correct then the chances are excellent that no thought was given to making the context of the application simple to preserve and restore. Logging out and logging back in is probably your only truly feasible alternative.

If a miracle has happened and that isn't a problem... you also have the issue of getting the clients to notice new r-code. That is actually quite easy in theory although less simple in actual practice -- you just need a way to reset session:current-language for all sessions. Which your signaling method could, in theory, accomplish. I'll warn you though that writing socket code in the 4gl is not for the faint of heart. Those kbase articles above leave out a LOT of gory details that will bite you and you are very likely to pull all of your hair out in frustration as corner case after corner case trips you up.

Frankly I would first focus on making sure that the basics of redundancy are properly implemented and well managed. Then I would start to get into exotic territory like seamless fail-over.

 

[RealHeavyDude]

I can only second what Tom said.

The foundation of high availability and the fewest possible downtime is redundancy and load balancing. We have a completely redundant system in place that uses load balancing. I've yet to see an absolutely seamless switch with not one single client being affected. Although it takes only a small fracture of a second to have the load balancer recognize a system being down, during peak times, exactly during this smallest of small time windows a request might still be routed to the system which is down and thus failing.

I need to point out here, that you can not achieve such a solution with fat clients that have a database connection and r-code that is exectued on the client. Fat clients that lose the database connection for whatever reason will always encounter a STOP condition. Although you are able to handle a STOP condition gracefully there is no way to fail over the database connection. Even if that were possible there is still a security issue in failing over an authenticated user identity without exposing it on the client ripe to be stolen by an attacker. Persisting any kind of authentication/authorization credentials or single-sign-on object on the client is a NO GO.

Whatever you are trying to do in order to minimize downtime during deployment - if you want to reduce the downtime to an absolute minimum you need to make really serious investments in redundancy and load balancing and modern application architecture.

Heavy Regards, RealHeavyDude.

 

[ForEachInvoiceDelete]

Totally agree with the above.

I was merely suggesting a way to fulfil the first requirement of "Is it possible to pass value across sessions in Progress without using DB/File?".

I still have nightmares from the couple of weeks playing with sockets in Progress

Intelligent Load balancing is absolutely key to maintaining high system availability. The first thing i would do if presented with the situation of inheriting a fat client application is figure out how much work it would be to migrate to a more N-TIER architecture with PAS.

 

[catch.saravana]

@TomBascom @RealHeavyDude - I agree with you.

We are in the process of exploring the options that are available and consider what all can be taken up as part of this migration project. On a lighter note DBA's who have handled different db's throw their ideas to see if the same would fit into progress world; so we are documenting and testing.