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
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
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
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.
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.
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
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
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
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
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
Thanks James,
I've done this, and am encouraging the other developers here to get on the bandwagon.