to Matijn Woudt: you are right there should be something like: public
void synchronized increment(), but that is not the point. Sure there
are disadvantages and other problems but what Alessando is saying is
"I would not use cure for cancer even if it existed because it can
introduce other problems like overpopulation". There are cases when
"application server" adds much overhead that is not needed and there
are cases when it simplifies your tasks a lot. So from his mail the
only problem I can see is memory leaks, and I am not talking about
leaks in application because they can be caught in tests and fixed,
but mostly leaks in poorly wriiten PHP core and modules. Other like
session hijacking are not real problems (other languages somehow
managed it to work) or not so big in face of some other advantages
(like restarting application after change).
Robert Williams points that the main problem is with PHP programmers
who tend to ignore many aspects of multithreaded programming and PHP
helps them in that by hiding all threading aspects. There are still
people who can understand that and take profit from this knowlege.
The memory is also not such problem. I did some quite large PHP
projects and whole source code event if it were loaded in memory use
only few megabytes (event 100mb is not a problem). And am talking
about holding parsed structures in memory not the source files.
Applications I am talking about are mostly targeted to maximize
throughput and they are the only ones on server. In such cases *any*
speed improvement is worth attention.
I am not forcing anybody to use application server approach, but
rather like Robert said - good to have choice and decide on my own if
I want to write simple scripts or stateful application. The only
problem is that I do not have that choice not considering changing
language... at least I do not have such choice for now :)
2012/9/26 Robert Williams :
> On 9/26/12 10:18, "Matijn Woudt" wrote:
>
>
>>Writing scripts for an application server requires a much deeper
>>understanding of threads and computer internals,so as a result it
>>probably increases error rate.
>
> Well... yes and no. PHP's architecture pretty much keeps you from having
> to mess with thread management, but it does so by shifting the burden to a
> higher level, either process management of multiple PHP processes or
> thread management within the context of the HTTP server. If your
> application is sufficiently simple, that shift may be enough to keep you
> from having to worry about the problem. For most applications, however,
> it's still a concern. In some ways, this can make things worse, simply
> because PHP programmers tend to be oblivious of the potential problems,
> whereas the typical C# or Java programmer has at least some awareness of
> the various traps that await them.
>
> As an example, I see PHP code *all the time* that is wide open to
> concurrency issues with the database. Most code just assumes it's the only
> code doing updates, but unless the server is set up to serialize requests,
> that's an invalid assumption. Recently, more folks have started to address
> this by using database transactions, but this is often done in ignorance
> of what isolation level is being used and what the impact of that is upon
> the code - which can just make things worse. Even when there is that
> awareness, there are database concurrency issues with which transactions
> can't help. (Of course, people who are aware of isolation levels also tend
> to be aware of other concurrency issues.) The point is, if you have
> multiple things running in parallel, whether that be threads within your
> application or entirely separate physical servers running multiple copies
> of your application, you have to deal with concurrency issues. It's a
> necessary evil of parallel programming, and no mere technological solution
> (language, database, whatever), now or in the future, can fully overcome
> it. Well, maybe an AI engine somewhere in the chain, but that's about it,
> and that's not coming anytime soon.
>
> Incidentally, another advantage of PHP's share-nothing approach that
> hasn't been mentioned is relatively easy scalability. In a shared pool
> architecture, the easiest way to scale is typically vertically, that is,
> adding RAM, faster drives, etc. This is fine, but you can only scale
> vertically to a certain point, which you can usually hit pretty quickly.
> With PHP's share-nothing approach, you can still scale vertically, but you
> can almost as easily scale horizontally by adding more servers that each
> run merrily in their own worlds, with the primary added coordination logic
> being in the areas of communicating with the database and the data cache,
> something the application should be designed with, anyway. In contrast,
> the shared approach requires added logic, somewhere, to coordinate the
> sharing amongst the pools of all that data that the application takes for
> granted is always available
