pardon me, but is that function writing to the database for each page view?
No, only views which hit a stale copy of the rendered page and have to call that render() function. Normal views would (I imagine, I haven't traced it back) use the get_rendered() instead, which checks that the cached version is current and schedules a re-rendering (which obviously requires DB writes anyway) if necessary.
Yeah - looks like it's emulating a lock so only one page can be rendered at a time (plus the overhead for database IO to maintain the lock). Is this really the best way to go about this?
Unless I'm missing something important, it's locking so the same page can only be rendering once at a time; if another request that would cause a rebuild comes in while a previous rebuild is still in progress, it gets bounced.
Yes, you are correct. We're trying to limit the system to one rendering per page at a time.
Seems to me it's actually writing to the database twice for each page view; once to update the render_started_at property on #845, and once again on #881.
That render() method is called only on page edits or forced refreshes, not on every page view.