Caching problem?

Been like that since the site switch, hasn’t it?

Ken,

I think so, but I didn’t visit BPL from last June until January of this year, and the switch had been running for a while. Since it happens on more than one device, it must be the site and not my equipment. It’s quite a pain at times.

Hi Nick

The Back button on your browser uses a list of URLs held by your browser. All that happens is that your browser goes to a previous URL. Not sure how that is the fault of BPL, but anything is possible.

Cheers

Yeah, caching can be difficult.For example, in “Recent Posts”, I might spend a few minutes replying to a post or simply reading through a few postings. Returning to the “Recent Posts” screen, it will re-build the screen to match the current listing…which means going through the whole database again and reposting a snap-shot of the current state.

This has a way of really slowing things down as the database goes through and updates the current screen. I believe the program just sets a global flag that the picture on screen is out of date and a viewing will force a screen update. Similar to the old “curses” screen control in Unix based systems.

This is good and bad. It saves a lot of time looking for stuff, sorting into a natural menu list(chronological), and displaying on screen, if it does NOT do the update. All calls from your current computer should not always do a screen update. Even a clock change will trigger this. To avoid the near real-time updates, if nothing is changed in the database, nothing on screen needs to be updated. So, it is skipped, synch problems happen…watch the “time since last post” sometime. In any event, there is also some sort of timed refresh, 5 minutes I think. This will set the global “refresh” flag.

Personally, I would not do that. It really taxes the host machinery. All users get a free refresh whenever reading a post. But, I can simply hit refresh if I want to look at something new. Or, it will keep my place so I don’t have to find a post again. And it keeps response times much shorter. But others prefer to see the current state of the database all the time. It is a six of one, half dozen of the other type decision. For transaction processing, like a bank, such stuff is necessary. What if you draw 1000 buck from one account to another from two different locations? Which is the correct bank account balance? For non-critical stuff, it is too much work on the host computer since it requires a disk read/write…and confirmation it happened. (Disks  reads/writes are an order of magnitude slower than memory.)  Just running from memory can be OK, but on occasion (reboots, conflicts, etc) you can loose an occasional posting. Or you can implement something like what they have…a combination that is “not” guaranteed to be current with your screen, but never looses anything (well supposedly.) So, you get an occasional non-refreshing screen when two posters are making a nearly simultaneous update. The “refresh” flag gets cleared by one, so you get the old screen, rather than a new refreshed screen. It only happens sometimes, though. This is the system I believe they use.