D
dbeavon
Guest
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.
Continue reading...
Continue reading...