PAS to emulate state-reset (not resetting properly via sessi

Does anyone have an idea on how to properly use the QUIT statement to clear out the PAS agent session?  The important part is that this QUIT must be done in a way that ensures that the "Session startup procedure" is re-run as well.  The session's "startup procedure" is pretty critical, especially for state-free-type clients, since it initializes a lot of old-school "NEW GLOBAL" variables that our legacy ERP needs to work properly.  

The documentation has extensive details about how we were supposed to able to emulate "state-reset" (session-managed) behavior.   The docs also advertised the ability of a single PAS server to run both types of legacy session models.  I'm guessing the problems are related to the way PAS attempts to support *both* session models, possibly without proper regard for the differences in behavior between their various "event procedures".

FYI, I noticed that "session startup procedures" are handled properly in the scenario where an agent's session is timed out (see community.progress.com/.../36188). The startup procedures are re-run in any new session that is created after the previous MsAgent session was timed out.  But the QUIT statement seems to be doing something different.  Personally I think that any session in which the QUIT statement was used should be marked as a poison session and never re-used (ie. the session should be allowed to time out, and get cleaned up).

Can someone who has used "state-reset" behavior on PAS please comment?  At this point I'm wondering if I should revert to creating separate PAS servers for "state-reset" behavior, so that my event procedures work properly and won't conflict with any of the clients that are trying to use the state-free-type behavior?

Any help would be appreciated.  I suppose I will open a support case if nobody else has experience trying to emulate "state-reset" on PAS.

We are experimenting with replacing our classic appservers with PAS.  I just did a test with classic state-reset where I created a global shared variable in the appservers startup procedure and gave it a value.  I define the shared variable in the connect procedure and display the value in the appserver log.  When I connect to the appserver the first time, the value is correctly displayed in the log file, when I disconnect and reconnect, the value is blank.  I did the same with PAS using the bind, unbind, and quit statement and get the same results.  I don't believe that anything which was created in the appserver startup procedure persists in a state-reset appserver once it gets reset.

Thanks for the reply Blake. I agree that a reset operation clears everything out. The problem is a bit more involved, and seems to do with poor co-existence of state-reset and state-free requests on the same PAS instance.

Lets say I have a global variable initialization operation ("GVI" for short).  In practice we also do some other setup operations during the "GVI" like setting a user's SESSION:TIMEZONE, and so on.

For "state-reset" ABL sessions there are three steps:

A - Connect Event Proc (GVI executes here)

B - Run persistent proc and then its internal member proc

C - Disconnection (which clears out session data)

For "state-free" ABL sessions these are the intended steps:

A2 - Session Startup Event Proc (GVI executes here on a one-time basis - so all subsequent requests are very fast)

B2- Run persistent and then its internal proc

C2 - repeat at step B2 for all new client requests.

(Note: where state-free is concerned, GVI globals remain unchanged and are never intended to be cleared away)

Because GVI executes per-user-request for state-reset requests, and per-agent-session for state-free requests, there are minor limitations in what kind of code can be run on what type of appserver.  Typically we use state-free requests for read-only operations and we make state-reset requests when updating data (safest bet because it is most compatible with 20-year-old legacy code).

So the problem that I am seeing is when a "state-reset" operation goes A1->B1->C1 and leaves the ABL session in a state where its GVI globals are cleared away.  A "state-free" client request then comes in (at step B2) and assumes that the GVI has already taken place.  But because the "state-reset" client has previously stomped on the session, it is no longer usable (except, perhaps, by another "state-reset" request).

Hope this makes sense. I think the root of the issue relates to the purpose of the "session startup" event proc. My understanding is that its purpose is to initialize ABL sessions (eg. ABL globals, SESSION:TIMEZONE, etc.)  If this is the case, then clearly PAS should be responsible for re-running the session startup event proc after a QUIT statement, or things won't be properly initialized anymore (its exactly as if PAS forgot to run the "session startup").

I don't mind a work-around*** but I wanted to point out that migrating state-reset behavior to PAS wasn't as straight-forward as the docs seemed to imply.  Please let me know if I'm overlooking a better work-around or if we aren't on the same page about what "session startup" means.

Thanks,

David

PS *** My work-around may be to run state-reset operations on a separate PAS instance since they don't seem to play nice with others.  Another option might be to write a fancy Activate event procedure which detects a session that isn't properly initialized yet and fixes it.  However, I was hoping to stay away from using activate/deactivate procedures to avoid performance issues and additional complexity.

We too run session level processing, instantiate session persistent procedures from the startup program.  We have processing in our activate/deactivate procedures which test for the existence of them and initializes them if they don't exist.  

I'm going to look at them further and make sure that it is all working correctly.

I agree it is not as simple as it may migrate to PAS as it should be, at least if one tries to use one instance for both state-reset and state-free.  We may end up starting 2 instances, 1 for our state-reset connections and one for our state-free connections.  I believe there is a way in which one can put 2 oeabl web applications under the same instance, each having its own set of abl agents I'm experimenting with that also.

David,

We have a bug here in the Product and documentation. We have to fix the sessionStartup part for State-reset based applications. I can log a bug for it, but if you would like to raise a TS case so that you can have a track it then please do.

So as an alternative, you can run two different ABL Applications in a single PASOE Instance. This gives the ability to run two different session-managers which can have their own event procedures, PROPATH, database configurations and agents.

Here is the quick kbase for you on how to create ABL Application -

knowledgebase.progress.com/.../How-to-create-multiple-ABL-applications-in-one-single-PASOE-instance

Thanks Irfan.  I created the case ( #00426507 ).

Thanks also for that KB.  I had wondered in the past whether a single tomcat server would be able to host multiple ABL applications.  In the OEE U/I these two logical levels seemed inseparable. While there is an HTML table of "applications", there is only one entry in the table and it has the same name as the instance.  There are no operations available in OEE (as far as I can tell) that indicated an actual one-to-many relationship; I thought the table of "applications" was just a U/I design problem.

Thanks for the tip, David