[TYPO3-core] RFC #12130: Improve performance of flashmessages

[Ernesto Baschny [cron IT]]

Rupert Germann schrieb:
> Ernesto Baschny [cron IT] schrieb:
>> So I suggest to keep it like it, don't use $_SESSION and then open
>> another issue where the $BE_USER session handling can be configured to
>> use PHP's session instead of our own be_session table in DB.
> 
> well, i have a bit the feeling that we're turning in circles here...
> I made a patch where I stored the messages in $GLOBAL[T3_VAR]
> not good said masi.
> I made a new patch where the flashmessages are stored in a static var in
> an object (my personal favorite). not good said Francois and Xavier.
> I made a new patch to store the stuff in $_SESSION...
> not good says ernesto.
> Do you know the great "Little Britain" running gag called "Computer says
> nooo"? ;-)

It is cool that you are so fast in adapting to our wishes, but in this
case (and in others) it might be helpful to first discuss the issue a
bit to see what the general consense is, because as you have noticed, we
haven't reached a consense yet. And for discussion of course the
typo3_4-3.general might be more useful.

> btw: $_SESSION['login_challenge'] is used quite often in the core, so it
> seems that we rely on that it is there.

With "quite often" you mean once. :)

PHP session is not something we usually use for storing BE session
information. The drawback is the multiple-webserver configuration I have
mentioned, as PHP sessions are usualy webserver local and a TYPO3
installation can spread upon multiple webservers. But this is of course
an edge case and usually the sessions are kept on the same webserver.

We have had user->ses_data for ages for storing BE-session information,
and we have no "official" support for PHP sessions.
$_SESSION['login_challenge'] is the only thing that uses it, and the PHP
session is only initialized then. There is no PHP session in the
frontend and there is probably no PHP session if some alternative "login
mechanism" changes BE login securitylevel to something else than
superchallenged or challenged. So because of that I find it "weak" to
simply assume PHP session is there while it might not be.

So assuming that we need these flash messages (at least some) to survive
one request and assuming PHP session might not be initialized, I still
think it would be best to:

1) keep using $BE_USER->getSessionData() and
$BE_USER->setAndSaveSessionData()

2) provide a configuration option so that these methods can also use PHP
sessions instead of be_session table. And start PHP session "early" and
in some global place in this situation.

Cheers,
Ernesto