[TYPO3-core] FYI72: bug #9645: Memcached backend is not working properly

[Dmitry Dulepov]

Hi!

Martin Kutschker wrote:
> Dmitry Dulepov schrieb:
>> PATH_site will have problems if you have, for example, typo3.com and
>> typo3.org in one installation.
> 
> That's what I don't understand. Why do I need two caches in memory? The
> "traditional" DB cache was also shared between all domains.

My example was wrong... It is about one memcached server serving
different installations. If you have pages with the same uid in
different installations, you cannot store them in the same db,
right? For Memcached, you typically ~want~ only one instance of
Memcached to run, so you must be able to store pages with the same
uid from different installations in one Memcached. So you need to
distinguish between them. This is where host name comes into play.
It seems that PATH_site here could actually be an option too. I will
experiment tomorrow. I feel that HTTP_HOST is more safe though.

>>> As this is a FLOW3 backport I would appreciate if any changes made to
>>> the caching framework are done in a coordinated manner. It's great that
>>> you've made this finally run, but please wait with the commit until one
>>> of the FLOW3 team had the chance to review the patch.
>> Ok but they have different architecture and therefore some of our
>> changes (like SCRIPT_PATH) are irrelevant/useless to them. If they
>> don't review the patch, we will have to drop memcached backend from
>> 4.3 completely. We can't ship a piece of code that does not work at
>> all...
> 
> Don't be so rash. I only asked for a little time so that the other team
> may make some comments. But if course, I didn't know if the changes are
> relevant for FLOW3. But as you've removed the site prefix you have at
> least changed the API a bit.

I do not rash :) I really think we should not ship it unless it
works. We never did before, we should not do now :)

As to API change - not necessarily. Getter/setter is gone but they
are not really a part of API because they are called dynamically if
you set an optional parameter in the configuration, whcih is not
even there by default or documented. So I see no problem with it. My
goal is to make this nackend flexible, safe and easy at the same
time :) People should be able to say "Ok, I want memcached" and
that's it, it should just work without any additional server IDs or
other cryptic stuff :)

-- 
Dmitry Dulepov
TYPO3 translations support
My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book
In the blog:
http://typo3bloke.net/post-details/typo3_43_cache_and_memcached_fix_ready/