TYPO3-Documentation / TYPO3CMS-Reference-CoreApi

"TYPO3 Explained": Main TYPO3 Core Document: Main classes, Security, TypoScript syntax, Extension API and much more
https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/
21 stars 376 forks source link

Documentation is missing information about the Locking API #85

Closed markwatney2016 closed 5 years ago

markwatney2016 commented 7 years ago

A new Locking API was introduced with TYPO3 CMS 7.3 but there is no further information about it in the documentation.

Details: https://wiki.typo3.org/TYPO3.CMS/Releases/7.2/Feature#Feature:_.2347712_-_New_Locking_API

It may be helpful to describe:

sypets commented 7 years ago

+1

Information addressing not just developers but hosters (hosting and configuring TYPO3 regarding server architecture and cache setup etc.) is welcome.

The description of the Caching framework (https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/CachingFramework/Index.html) is already very helpful in my opinion.

I'm especially interested in best practices and the conceptual ideas.

Some questions:

Answers to these questions can be found in a number of places, including forge, the forums, stackoverflow and slack. Making the information accessible in one place and making it more "official" woud be very helpful.

sypets commented 7 years ago

Some example where information already exists, that could be useful as a starting point, but partly needs to be validated if still applicable:

sypets commented 5 years ago

I submitted a PR #363 for this. It does not answer all questions posed above, but it is a start.

However, I ran into some questions of my own:

liayn commented 5 years ago

Correct. We thought about such a layer already, but it is almost impossible to have such a generic layer. The locking needed highly depends on what the application wants to implement. In the case of TSFE we have the extreme thing with a nested locking approach to get maximum performance an close to no wait-time. Locking is indeed missing in a lot of parts in the core, not only around caches. I'm open for any suggestion regarding such a generic layer though.

sypets commented 5 years ago

@liayn Maybe, for the extension developers, we can add code examples / best practices to the "TYPO3 explained" docs.

We (I @ work) use the Caching Framework in an extension which we developed here and I always assumed the Caching Framework used locking internally (not that anyone ever said this). Well, it doesn't and I think I should fix this now in my extension. If I'm adding the code now, it's probably not much extra work to create a PR adding some of that to the documentation and maybe you or Lolli can have a look.

For using (caching with) locking in the core / general layer: That does sound like not an easy job indeed. The more I document and read through the code, the more I hope I can make useful suggestions, but too early for me. Not an expert on this. If you can take that topic up with core team / decisions, would not be unhappy about that.

If anyone can point to some general concepts / good resources (must not be TYPO3 specific), might also be helpful.

liayn commented 5 years ago

The thing is that it depends on how you use the cache. Is it a simple reader-writer problem? Are there potentially multiple writers? etc etc

In terms of extension dev support I don't see the problem in the code-wise mechanics but more on the educational level. People often do not keep in mind that a website is an application with a lot of parallel processes. PHP too often gives you the impression one works in its own ecosystem. This assumption is broken in the second one reads or writes to a DB or a file.

For instance in the core itself:

So there's endless amounts of work to be done. Start where it hurts most.

sypets commented 5 years ago

PR was merged: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/LockingApi/Index.html