File reader/writer model

molesquirrel

This is a rather simple situation. I've got a template engine that over the course of one page request will include() one/several file(s). Simple enough.

This particular site does not have scheduled updates as much as I'm always tinkering with the code, often to fix a one/two line bug that a user takes note of. Right now, I'll just crack open the ftp client and upload that sucker. In the past, this would work fine, but now, the second it might take to upload a file is enough time to register a few include() requests for that file. php reads the file (which is in mid-upload), doesn't get all of it, then throws a parsing error when it doesn't find the rest of the file.

So, I'd like to write a simple 'update' script that locks the file, upload/overwrites it, then unlocks it. flock() seems to be what I'm looking for, but I'm not entirely clear on its effects. Since this is being done to prevent problems in a high traffic situation, it's not something I can easily replicate on a dev server. So, I'd love to know the following:

a)when a file is flock()ed, do any other requests to create a file pointer (for reading) on that file get rejected, or just get blocked until the lock is released?
b)The php docs state

PHP supports a portable way of locking complete files in an advisory way (which means all accessing programs have to use the same way of locking or it will not work).

Now...does this mean that my templating program needs to have code that checks for a lock of sorts, or can it access the files in the same way it always has (since it's only acting as a reader, and not a writer)

From looking over the code samples in the docs, the writer process might need to loop before it can acquire a lock, but since the readers don't need exclusive access, they won't need a lock, and therefore won't need to ever do a sleep loop, right?

As always, thanks in advance!

devinemke

why don't you simply halt the page load if your include fails and do a client-side meta refresh? let's say the included file in question is called "file.php":

$include = @include('file.php');
if (!$include)
{
	echo '<meta http-equiv="refresh" content="2; url=http://www.molesquirrel.com">';
	exit();
}

if the include fails then the page will be refreshed in another 2 seconds (and so on...)

molesquirrel

Only problem with that, though, is I would expect that @ sign to do a lot of unwanted error supression. I've got error reporting turned on, and everything is funneled off into a custom error handler, but if I clamp down on the entire file that's being included, wouldn't I lose error notices incase I have a runtime error, etc, etc?

devinemke

Originally posted by molesquirrel
Only problem with that, though, is I would expect that @ sign to do a lot of unwanted error supression. I've got error reporting turned on, and everything is funneled off into a custom error handler, but if I clamp down on the entire file that's being included, wouldn't I lose error notices incase I have a runtime error, etc, etc?

the @ only supresses the error of that function call which is exactly what we want here. we are trapping the error and conditionally halting the script. by calling the exit() function you aren't going to have any runtime errors, the script is stopped right at the failed include(). the whole point of this is to completely halt the script if a given include file is unavailable and do a refresh (until is it available).

molesquirrel

Interesting. Two notes:

1)Could the meta refresh be duplicated internally with a sleep() function of some sort with php?

2)A few (but not many) of the scripts I include return values, like...

$resultMsg = include('babies.inc');

so this would prevent that.

Oh, and one more thing. Ideally, I would like to stay away from putting in a check like that (or factoring the check out to an includeFile() method), and try to focus on having the Writer (update script) intelligently manage this. The template engine in question backs a few sites, and while I neglected to mention this earlier, there's no guarantee that there will be additional include() calls outside of the templater, and there's really no telling as to what kind of files I might be updating, and where they're called.

What I'm asking for may be impossible, but I want to aim for complete transparency on the part of anyone acting as a Reader (templater, extraneous files, etc), and do all the locking/unlocking in the Writer. If you can state for a fact that this is impossible, let me know and I will focus my efforts on an alternative method (like the one you've been describing) instead.

Thanks for your responses thus far!