[TYPO3-core] RFC: Bug #7630: Locking Problems with TSFE->set_no_cache()

[Oliver Hader]

Hi Jeff,

Jeff Segars schrieb:
> This is a SVN patch request.
> 
> Branches: 4.2
> 
> Bugtracker Reference: http://bugs.typo3.org/view.php?id=7630
> 
> Problem:
> The locking API has problems if an extension sets TSFE->set_no_cache().
> 
> When a page is rendered, a lock is generated as long as the page itself 
> isn't set to be uncached. At this point in time, we know nothing about 
> what individual extensions will do with page caching. When rendering 
> completes, we release the lock and again check to see if the page is 
> marked as uncached, which it may be because of an extension calling 
> TSFE->set_no_cache(). If the page is now marked as uncached, we don't do 
> anything with locks which in turn leaves us with an open lock. 
> Subsequent reloads of the page will take approximately 30 seconds due to 
> the open locks.
> 
> Solution:
> Release the locks within TSFE->set_no_cache().
> 
> Notes:
> The attached patch also contains some sysLog output for easier debugging 
> of the problem.  This should be removed prior to commit so that only the 
> lines within set_no_cache() and releasePageGenerationLock() are changed. 
>  I've also attached a test extension on the bugtracker.  All it does is 
> set TSFE->set_no_cache so you can easily see the behavior before and 
> after the patch.

Thanks for your patch. The debug during development is fine, maybe we 
can introduce a global configuration property to toggle this logging via 
install tool / typo3conf/localconf.php?

Releasing locks in $TSFE->set_no_cache() is one possibility, but if an 
extension just sets $TSFE->no_cache=1 it won't help. I tend to always 
check for and release the locks even if caching was disabled at the 
beginning.
Please have look to my attachment which solves the following:
* always release aquired locks, no matter if no_cache is set
* always remove (additional to release) semaphores to prevent leaks
For further details see the post discussion of RFC #7333 in the 
bugtracker [1].

What do you think?

olly

[1] http://bugs.typo3.org/view.php?id=7333
-- 
Oliver Hader
http://inpublica.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007333_post_v2.patch
Type: text/x-patch
Size: 2112 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20080224/2effc5c4/attachment.bin