[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