Webspeed displayed wrong values

Y

yoachan

Member
Hi All
I have a problem that have been bugging me for ages, I don't know if any of you ever had the same problem, but some of my friends did....

I'm using OE 10.1B and webspeed.
My problem begins when I'm building reports using webspeed. Just a simple report to display my table's contents.
e.g.

Code: 
.....
<%
    FOR EACH table_x NO-LOCK.
%>
      <tr>
           <td>`table_x.field_name`</td>
           <td>`table_x.field_value`</td>
      </tr>
<%
    END.
%>
....

the problem is sometimes when I change field_value, my report still display it's previous value. It's like webspeed is buffering my table's value. And FYI it's this syndrom happens on few updated records. Not all records. so in my reports some values updated, and some other still the same. But the next time I refresh my report it displayed all updated values.

My friend told me to use EXCLUSIVE-LOCK instead of NO-LOCK to force webspeed to always check fields value properly. At some poit my friend was correct for my reports always display my records' latest value. But I don't think that using EXCLUSIVE-LOCK is a proper solution for this.

PS. restarting webspeed broker makes this problem dissapear for some time, but it will appear again after a period of time until the broker rebooted again.

Any help appreciated.

my best regards


YoChan
 
It doesn't make much sense. I mean your statement about the buffer, because you say it happens only for a few records, or you mean just the updated ones? If just for the updated ones it is happening than it is a strange behavior, but if only for some, it does not make much sense.
I've been working with webspeed in the past but did not ever encountered such problem.
Have you been checking the logs?
I'm not sure, but can you do an XREF on a webspeed source file and compare the NO-LOCK and EXCLUSIVE-LOCK results?
 
-rereadnolock Startup Parameter is needed.

This startup parameter changes the behavior of NO-LOCK record retrieval. It was introduced in 8.3B.

When a PROGRESS client (4GL, AppServer, web-agent) makes a request to find a record with NO-LOCK, it will not always get the newest copy of the record. If the record is already being used NO-LOCK by another 4GL buffer then the old copy usually remains in memory rather than replacing it with a new copy. This behavior is not always desirable.

The basic mechanism that accounts for this behavior works like this. PROGRESS first fetches the record from the database. PROGRESS then takes the ROWID of the record and compares it to the ROWIDs of records that are already in memory, in use by other 4GL buffers.

If the ROWID matches one of the records in memory, PROGRESS usually discards the new one, instead of the older record. This does not happen when the new record contains more information than the old one, for example, when the new record has more fields because it was based on a different field list.

The -rereadnolock startup parameter causes PROGRESS to discard the older record and replace it with the latest version.
 
Just back from outer space....
Thanks for your reply.

@enoon
It makes sense :)

@Cecil
Where should I put this -rereadnolock? On Database's startup param or in my wsbroker properties?

Regards
YoChan
 
It's a client side parameter so put it in the WebSpeed agents configuration.
 
do you mean on the srvrStartupParam?
If it is, should I put -rereadnolock after each connected database or only need to put it once.

e.g.

Code: 
srvrStartupParam=-p web/objects/web-disp.p -weblogerror -db /datatrial/database1 -S 70001 -d dmy -yy 1980 -db /datatrial/database2 -d dmy -yy 1980 -S 70002 -rereadnolock

or

Code: 
srvrStartupParam=-p web/objects/web-disp.p -weblogerror -db /datatrial/$database1 -S 70001  -d dmy -yy 1980 -rereadnolock -db /datatrial/database2 -S 70002 -d dmy -yy 1980 -rereadnolock
 
The first example given, is all that is needed.

Remember to stop and start the WebSpeed broker or trim the agents for the changes to take effect.
 
It can also be the Web Server or the browser who are caching your web page and sending back the same result.

ie your page is

www.yourdomain.com/cgi-bin/cgiip.exe/WService=wsbroker/yourprog.p

You call the page the first time , Your web server cache the page. If you ask the same page after you change the data , your web server will consider it the same page your requesting and send his cache instead of calling webspeed again. (Same thing for the browser).

To test this , if your bug comes back meaning it more of a cache problem then a rereadnolock then you can add false data at the end of your URL to trick the web browser and see if it really him caching it.

ie www.yourdomain.com/cgi-bin/cgiip.exe/WService=wsbroker/yourprog.p?FALSEDATA=NOWAY

This will be considered a new URL for the web browser and he will not cache your page .


You can fix that in your pages by using the HTTP HEADER cache-control
 
You must log in or register to reply here.
Back
Top