I'm currently rewriting part of the legacy webspeed application to make use of PASOE features (and by the way going OO). One of the goal, it's to able to share session's data between instances.
Session's data is kept in 2 tables in the database.
If I wish to offload specifics read-only requests to the OE-Replication database. The replicated database will eventually contain the data at a given time but it is out of my control. If I create a session in the production database and redirected right away the client to the PASOE instance that is connected to the replicated db, it may fail because of replication lag/workload.
Not sure if Tomcat load balancing can help me on this one.
So, I'm looking of another way to handle session's data. I know that mechanisms already exist in Tomcat ecosystem (Spring, Redis, Memcached and so on). But they are all into Tomcat side, not ABL.
How can I have my ABL code talking to the Tomcat/Spring stack to read/write values into the Tomcat session ?
If not, what other fast and reliable ways are possible ?
Can you describe the problem a bit more clearly? Do you have two different abl apps (and webapps) that are each connected to a different version of the database? And one of the databases has a bit of additional latency (and is read-only)?
Will the front-end continue to be webspeed?
Are the "sessions" that you mentioned for tracking the front-end users (ie. they are long-lived sessions), or are they created for the sole purpose of the short-lived work that is being done in PASOE?
>>If I wish to offload specifics read-only requests to the OE-Replication database.
I don't see why you can't use a connection to *both* the primary *and* replicated versions of the PASOE abl app. One is for managing your session data and the other is for offloading the larger reads (or whatever). Why do the two PASOE need to share any "session" data? The front-end can coordinate with a common ID of some kind and allow each side to "maintain" the portion of the session-state that it cares about. For "maintaining" the PASOE session, you could easily use session-managed APSV model. This will hold the data in PASOE memory between round-trips so the front-end doesn't have to keep reminding the PASOE application about the full session state.
Thanks Peter for your input.
I already use Kafka in another project but I may be overkill for just a small session management.
If I use built-in ABL features to make REST call to, let say Apache Ignite, to retrieve/write session. Do you think the overhead cost will affect the performance ? Sure it will, but how much ? I know, this question is hard to answer. I was just wondering if the ABL APIs are performing well enough to consider this approach.
Briefly,
- it's a legacy CHui app (15+ years old).
- a webspeed classic app was added in 2006
- a native mobile app was added in 2013 (using REST-like call to webspeed)
- login, work, logout style development, so long-lived sessions.
The clients (both web and mobile) only holds the session ID. So every requests, the framework retrieves user info and some application related values from the session management tables. One of the purpose is to set shared variables to be able to call legacy code.
The database is under OE Replication Plus, so I can have a PASOE instance running and connected to that database in R-O mode. Goal is to offload some (not all) read-only requests to that instance. This will first relief the primary PASOE instance and second put less workload on the main database.
I hope these explanations can help to understand.
(double post, removed. Seems there is no way to delete a post)
I would think the best solution to your problem is to always use Openedge Database for all session requests (Read/Write/Update)
With this approach, is there any performance impact that is affecting usability of the application from end user point of view?
If the session requests are overwhelming the application requests, does separate database for session data help?
PASOE session replication could also be a solution, if both your PASOE instances are in the same network and discoverable. AFAIK, PASOE session replication is in-memory and can't be backed by persistent store. I could be wrong, though.