-rereadnolock for OEPAS

Posted by mroberts@rev.com.au on 16-Aug-2017 00:44

Hi All,

OE 11.7.1

We are using PASOE, and have just found that -rereadnolock is not working for us.

We have user A updating a record status in a PAS based web app to "Confirmed".

User B updates the status via classic appserver and a GUI UI to status "Cancelled"

User A goes and gets the record again no-lock, and the status is still "Confirmed"

Debug code in the PAS called code shows that the read of the record is returning the "Confirmed" status, even though the GUI app and an editor session show the new Cancelled status.

Out thought has moved towards -rereadnolock, and whether it is set.

We *thought* we had it set OK, adding it to the pf file that is referenced in the agentStartupParam

agentStartupParam=-T ${catalina.base}/temp -pf ${catalina.base}/conf/startup.pf

startup.pf has -rereadnolock in it

We know that the pf file being read, as the db connections in there are being used OK, so that cant be the problem

Looking at PAS  migration for -rereadnolock

https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop/setting-the--rereadnolock-parameter.html

It implies that the sessionStartupParam in openedge.propeties should be set.

This is where the confusion sets in

openedge.properties does not have a sessionStartupParam

https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-migrate-develop/migrating-classic-appserver-properties.html 

makes reference to AppServer.Agent.sessionStartupParam

When I use oeprop to try to add sessionStartupParam, it returns Property not found

When I add it manually, it does not seem to pick it up

So my dilemma is

1) Do I have the -rereadnolock option in the wrong property for it to work (in agentStartupParam or sessionStartupParam)

2) Do I have it in the right spot, and for some reason rereadnolock is not working

Anybody got any thoughts on this one?  I'd like to clear up the confusion on the best place to set it before I dig deeper into whether it is not working at all.

Thanks

Mark

Posted by James Palmer on 16-Aug-2017 11:04

How is User A refinding the record? If it's using a RECID find then this bypasses -rereadnolock. Well unless that is fixed in 11.7.1.

All Replies

Posted by Michael Jacobs on 16-Aug-2017 04:44

Hello Mark,

The property you are looking for is:
    AppServer.SessMgr.agentStartupParam

    [AppServer.SessMgr]
              agentStartupPram

This is the property that is used to pass startup parameters to each ABL Session started within a multi-session Agent process.   
Trivia:  the prefix 'agent' indicates that the property spans all ABL Sessions in the multi-session Agent process.

There is obviously a documentation bug and we'll see that it gets fixed.

Mike J.

Posted by James Palmer on 16-Aug-2017 11:04

How is User A refinding the record? If it's using a RECID find then this bypasses -rereadnolock. Well unless that is fixed in 11.7.1.

Posted by mroberts@rev.com.au on 16-Aug-2017 17:07

Thanks Michael,

As the documentation was pointing to values that didn't exist, I wanted to make sure it was not e going completely insane.

I put a debug in the code that messaged out the session:startup-parameters to make sure that the -rereadnolock was in there.  I have had issues with logging parameters (log threshold, num log files) that now get ignored, so wanted to make sure that something more had not changed with this parameter.  

Mark

Posted by mroberts@rev.com.au on 16-Aug-2017 17:36

Hi James,

Thanks for the insight.

Yes, we use ROWID ... and closer look at the docs have exposed a hole in my knowledge that I had not noticed since -rereadnolock had been introduced.  Our legacy code does not rely on recid-rowid much, so adding -rereadnolock fixed a lot of problems, and we have relied upon it since then.  We made the assumption that -rereadnolock worked as it implied, as we had not been bitten by this feature.

When you have a large code base that uses rowid-recid sparingly, and lots of users hitting multiple appserver agents randomly to get records, and only some of them using rowid-recid with no lock, then the chances of getting "dirty" data is slim.  But as the light dawns in our brains this morning, we realise that this has been a low level issue in our app over years, and might explain the occasional unusual issue where the app behaves strangely because the job was cancelled, and the user still managed to update it, because an unfortunate no-lock read by rowid got old data, on an appserver agent that still had the record in the buffer.

On moving to PAS, and a web interface, we are using a new framework that relies on ROWID a lot, and with 1 user using the PAS agent, and other users still using the legacy appserver code (with classic appserver), we find the issue jumps out at us ... records are being updated in the classic appserver legacy code and not being reflected in the FIND that is passing data to our web framework.

I like your choice of words "unless that is fixed in 11.7.1" ... my expectation has always been that with -rereadnolock, ANY FIND will ALWAYS read the DB.   My guess is no, but I would be happy to know if this feature was seen as a bug and had a plan to be fixed.

Looks like a job ahead putting an extra FIND CURRENT in code wherever it may appear, but having the following retrofitted everywhere

FND record WHERE ROWID(record) = rRowID NO-LOCK NO-ERROR.

IF AVAILABLE record THEN DO:

 FIND CURRENT record NO-LOCK NO-ERROR,.

END.

Seems counter intuitive to me

Mark

Posted by mroberts@rev.com.au on 16-Aug-2017 19:47

Further detail on the above ... where we are doing a FIND with ROWID, we are using a local buffer defined in a method in a class

DEFINE BUFFER b1_customer FOR customer.

FIND b1_customer where rowid(b1_customer) = rRowID  no-lock no-error.

if available b1_customer then do:

   /* here we are getting old data, even though it is a locally defined buffer coped to the method */

  /* we now have to add the below line ... why? */

 find current b1_customer no-lock no-error.

end.

There is a likelihood that the default buffer customer has a record in it from some previous activity elsewhere, if it has the same ROWID, is our local buffer picking up it's remains?

Mark

Posted by James Palmer on 17-Aug-2017 03:16

I honestly thought I'd raised this in the ideas section as an enhancement request but I can't now find it. I've created a new one. Feel free to vote. community.progress.com/.../-rereadnolock_to_be_honoured_by_rowid_finds

Posted by James Palmer on 17-Aug-2017 11:22

Ah after some digging I've found the original request. I've requested the new one be removed. Please add your votes on community.progress.com/.../enhance_rowid_find_to_get_latest_record_from_database

Posted by mroberts@rev.com.au on 18-Aug-2017 01:25

Thanks James,

I've done this, and am encouraging the other developers here to get on the bandwagon.

This thread is closed