On 9/26/12 10:18, "Matijn Woudt" <tijn...@gmail.com> 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 at low cost.

Having said all that, there are many advantages and disadvantages to both
approaches. And honestly, I would love to have the option of a shared
approach with PHP, since that architecture simply works better as a
solution to certain problems. Assuming the shared-nothing model continues
on, it would make PHP that much more well-rounded. In that respect, the
added option isn't that different from the addition of OOP: we now have
the great ability to use procedural code where it makes sense, and to use
OOP code where it makes sense. Where neither is a perfect fit, you can
choose the one that creates the least personal pain. It's a wonderful
choice to have.

Robert E. Williams, Jr.
Associate Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority

Notice: This communication, including attachments, may contain information that 
is confidential. It constitutes non-public information intended to be conveyed 
only to the designated recipient(s). If the reader or recipient of this 
communication is not the intended recipient, an employee or agent of the 
intended recipient who is responsible for delivering it to the intended 
recipient, or if you believe that you have received this communication in 
error, please notify the sender immediately by return e-mail and promptly 
delete this e-mail, including attachments without reading or saving them in any 
manner. The unauthorized use, dissemination, distribution, or reproduction of 
this e-mail, including attachments, is prohibited and may be unlawful. If you 
have received this email in error, please notify us immediately by e-mail or 
telephone and delete the e-mail and the attachments (if any).

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to