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

[Michael Stucki]

Hi Olly & Jeff,

>> 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().

Thanks for taking care of this!

> 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?

Call t3lib_div::sysLog() and set severity to "info" (0). That should be
complitely fine for things like this.

So can you please incorporate the sysLog() calls from Jeffs patch?

> 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.

Well, usually I do not care about people who refuse to use the API
functions, but since it's easy to work around in this case, this is better
of course.

> 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?

Reviewed & tested, +1!

- michael
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/