[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