Web 1.0 Force session to keep alive

We have a situation where after the user completes a purchase on a web1.0 app then we need to call a third-party API (json).

But occasionally the user is finished and they will shut the browser session very quickly.

Unfortunately this happens before we get a response from the API.

Is there a way to keep the session alive until the response/ timeout is received and processed?

I think that is the wrong design. Why dont you make all the API calls in a global context instead of the session? Maybe store the result in a database and make the session request the result. This way you can even move the API calls to another web app.

Agree. But Im looking for a quick fix until we have time to redesign/ port to Web2

Increasing the WebApplication.SessionTimeout?

I believe Web session time out it’s only for inactivity while the browser is open. In this case the user may have even just close the lid on their laptop.

Run your code on the server and not the page. It sounds like the users browser is not needed for what comes after the API response. So stop running that code on the user’s page. Run it on the server.

You could process the request through a WebDialog with a spinning wheel to show something is happening, then when the process is done go to a “Thank you” page. This will teach users not to close the session too early.

Why don’t you get the API response on HandleURL ? It does not require a session.

Unfortunately sessions are tied to browsers so if the user disconnects, it will only stay around for a short time before it gets completely removed.

My advice is that when a request is sent off that he keep a record of everything he needs in a custom class instance that’s stored in a global dictionary which uses session IDs as keys. Then when the response comes back to HandleSpecialURL or HandleUrl, he can look up the corresponding class instance, use the stored data and remove it from the dictionary.

Here’s an example of how to do that: Download

2 Likes

Greg, example for web 2.0 ?

Everything should be the same except that the HandleSpecialURL code should be in HandleURL and you’ll need to pass both the request and response objects to the method that handles the callback.