[TYPO3-core] RFC: #7333: Solution for "Page is being generated"
Ernesto Baschny [cron IT]
ernst at cron-it.de
Mon Feb 4 21:48:41 CET 2008
Ernesto Baschny [cron IT] wrote: on 04.02.2008 21:39:
> Martin Kutschker wrote: on 02.02.2008 02:08:
>> Michael Stucki schrieb:
>>>
>>> As I consider mod_fcgid/apache2-mpm-worker as a great improvement and
>>> therefore think that we should not at all rely on the flock()
>>> functionality. I'm going to try to use mutex-locks and see if this works
>>> better...
>>
>> Apache offers quite a number of locking mechs. Seems the dev want to
>> put the burden of choosing the best (or best fitting) to the user.
>> Maybe we should do the same. Add a locking API and make the mech
>> configurable.
>
> I agree: we should have a core API for "locking resources" (e.g. page
> caching). We can start shipping with one implementation (e.g. flock),
> but have more options in future. Or course the API should be so cool
> that even extensions might make use of them. :)
>
> And then Bernhard can build his lockPageGenerate() method upon that.
> Bernhard, it would be cool if you could document your lockPageGenerate a
> bit "better" so that it might be easier to review that.
Maybe we could just take a look on how others resolved the issue.
Gallery2 is always a good candidate for consideration, because they
"have been there" with most issues we usually have in TYPO3. Their
locking API is pretty simple but nice.
Take a look at here:
http://gallery.svn.sourceforge.net/viewvc/gallery/trunk/gallery2/modules/core/classes/
* GalleryLockSystem.class = interface and "super-class" which all
locking sub-classes must implement
With the core they ship with:
* FlockLockSystem.class = our good old "flock()"
* DatabaseLockSystem.class = as they say in the header: "Database
backend locking. This is less efficient than filesystem based locking,
but is more reliable and portable"
Cheers,
Ernesto
More information about the TYPO3-team-core
mailing list