[TYPO3-core] RFC: #7333: Solution for "Page is being generated"

Martin Kutschker martin.kutschker-n0spam at no5pam-blackbox.net
Tue Feb 5 19:04:12 CET 2008


Michael Stucki schrieb:
> Hi Ingo,
> 
>> ok, fine. just as with Bernhard's patch:
>> please split lockPageGenerate() into lockPageGeneration() and
>> releasePageGeneration() or aquirePageGenerationLock() and
>> releasePageGenerationLock()
> 
> Alright, changed.


PATH_site.'typo3temp/pagegen_locks/'

The lock class is a general purpose class, so we need a different path:

PATH_site.'typo3temp/locks/'

>> * init -> __construct()
> 
> I disagree! First, the constructor would not allow any parameters. Second,
> it is not possible to reinitialize an existing object otherwise.

First is wrong, and second is no OO way anyway. Maybe you want a 
different class structure:

a master/factory class will bring you a lock object for a given id (but 
has no other methods). The lock class has acquire/release (but no way to 
set the is).

>> * acquire and release (private) methods should be split into several
>> methods instead of having large switches -> aquireSimple, aquireFlock,
>> aquireSemaphore, releaseSimple, ...
> 
> Later. I also thought about using separate classes for each method. This
> would make it easily extendable...

Yes, please. For 4.2 final we should have more classes.

I'm a bit unhappy that you have to refer to 
$TYPO3_CONF_VARS['SYS']['lockingMode'] when you instantiate a locking 
object. There is some merit that you can choose a mech at runtime, but 
it'd be easier if the method is optional (or '' would choose the default 
via $TYPO3_CONF_VARS).

Further there is no check if the method is available. System V IPC is 
not compiled by default (according to php.net) and is not available on 
Windows. So we need a fallback (and/or a check in the installer).

Masi


More information about the TYPO3-team-core mailing list