PHP and Threading - is it possible?

I've heard numerous and varied commentaries here and on other fora
regarding PHP and the concept of threads. Coming from a Java
background I understand how threads benefit to prevent collisions, all
the while carefully written to avoid "race conditions" while a web
application is being utilized in a multi-user environment.

However, are there examples in PHP alone where this same technology is
possible? I am faced with having to deal with the issue of potential
collisions within a web application I built since one user could delete
the exact same data/files/objects another user is simultaneously
creating, however, requirements are that the app must be
multi-user-friendly.

How can this be done in PHP, if at all, otherwise, what do you
recommend that is open-source and non-licensed?

Phil

re: PHP and Threading - is it possible?

comp.lang.php wrote:[color=blue]
> I've heard numerous and varied commentaries here and on other fora
> regarding PHP and the concept of threads. Coming from a Java
> background I understand how threads benefit to prevent collisions, all
> the while carefully written to avoid "race conditions" while a web
> application is being utilized in a multi-user environment.
>
> However, are there examples in PHP alone where this same technology is
> possible? I am faced with having to deal with the issue of potential
> collisions within a web application I built since one user could
> delete the exact same data/files/objects another user is
> simultaneously creating, however, requirements are that the app must
> be multi-user-friendly.[/color]

PHP is a stateless language, meaning that the objects exist only during the
request processing. In other words, in each request the script is run again,
and the entire environment (objects, their states etc) have to be rebuilt
from scratch. In practice, this means that on each call a different set of
objects are accessed, and the only common data is that stored in database or
some other form of persistence.

Berislav

re: PHP and Threading - is it possible?

comp.lang.php wrote:
[color=blue]
> I've heard numerous and varied commentaries here and on other fora
> regarding PHP and the concept of threads. Coming from a Java
> background I understand how threads benefit to prevent collisions, all
> the while carefully written to avoid "race conditions" while a web
> application is being utilized in a multi-user environment.
>
> However, are there examples in PHP alone where this same technology is
> possible? I am faced with having to deal with the issue of potential
> collisions within a web application I built since one user could delete
> the exact same data/files/objects another user is simultaneously
> creating, however, requirements are that the app must be
> multi-user-friendly.[/color]


People have been solving this for years without using threads. You're trying
to program in PHP as if it were Java - it's not. If your objective is
merely to assure exclusive access to files then build a mechanism to
implement it - like lock files.

HTH

C.

re: PHP and Threading - is it possible?

That is a major fundamental problem then. Because if what you say is
true, then in order to set up a persistent environment to handle
potential collisions, one would have to have the PHP equivalent of
BEA/WebLogic as an application server running alongside your
application to ensure an ordered persistent-state environment, which if
I remember there is nothing out there unlicensed open-source in
PHP-dom, if wrong, point me in the right direction, please.

Phil

re: PHP and Threading - is it possible?

Can you show me an example online of how you can, entirely in PHP,
ensure a "lock file" mechanism that will work in the PHP stateless
environment? That is, you lock.. something.

What do you lock? How do you lock it? I have MySQL "LOCK TABLE"
routines set up, but that doesn't prohibit the following fundamental
problem from occurring:

1) User A goes to associate two sets of database records together
2) User B, at the exact same time, happens to be DELETING the second
set of database records

I'm sorry but locking files and/or db in this case is simply not
practical. You would have to somehow lock the entire object
application instance STATE, across the board, to ensure that User A, or
user User B, depending on the connection pool, will get their action
logically accomplished.

Phil

re: PHP and Threading - is it possible?

"comp.lang.php" <phillip.s.powell@gmail.com> wrote in message
news:1107959913.131827.323580@z14g2000cwz.googlegr oups.com...[color=blue]
> Can you show me an example online of how you can, entirely in PHP,
> ensure a "lock file" mechanism that will work in the PHP stateless
> environment? That is, you lock.. something.
>
> What do you lock? How do you lock it? I have MySQL "LOCK TABLE"
> routines set up, but that doesn't prohibit the following fundamental
> problem from occurring:
>
> 1) User A goes to associate two sets of database records together
> 2) User B, at the exact same time, happens to be DELETING the second
> set of database records
>
> I'm sorry but locking files and/or db in this case is simply not
> practical.[/color]

Yes it is. I have been programming that way for 25+ years.
[color=blue]
> You would have to somehow lock the entire object
> application instance STATE, across the board, to ensure that User A, or
> user User B, depending on the connection pool, will get their action
> logically accomplished.[/color]

I don't know where you get your ideas from, but you do not lock an entire
APPLICATION or the STATE of an application, you lock the files you are about
to update/delete. If two users try to lock the same file at the same time
then it's a case of "first come, first served". The second lock will not be
allowed to continue until the first lock is released.

--
Tony Marston

http://www.tonymarston.net

re: PHP and Threading - is it possible?

The newsgroup comp.lang.php itself wrote:
[color=blue]
> That is a major fundamental problem then. Because if what you say is
> true, then in order to set up a persistent environment to handle
> potential collisions, one would have to have the PHP equivalent of
> BEA/WebLogic as an application server running alongside your
> application to ensure an ordered persistent-state environment, which if
> I remember there is nothing out there unlicensed open-source in
> PHP-dom, if wrong, point me in the right direction, please.[/color]

http://www.vl-srm.net/

Regards,
Matthias

re: PHP and Threading - is it possible?

Thanx, however, this requires PHP 4.3.7+, and I'm working with PHP
4.3.2 and 4.1.2 (this will be in multiple environments).

Sorry
Phil

re: PHP and Threading - is it possible?

Does your 25+ years of programming and "first come first served"
solution involve connection pools and NOT flat files as you are
implying.?? I'm not working with flat files in this case but with the
need for a persistent state that is, for example, illustrated within
Java's Thread-based objects within a connection pool. Can you using
PHP 4+ and MySQL 4 utilize unique concurrent connections to the very
same MySQL database instance?

Phil

re: PHP and Threading - is it possible?

"comp.lang.php" <phillip.s.powell@gmail.com> wrote in message
news:1107974616.392844.189300@g14g2000cwa.googlegr oups.com...[color=blue]
> Does your 25+ years of programming and "first come first served"
> solution involve connection pools and NOT flat files as you are
> implying.?? I'm not working with flat files in this case but with the
> need for a persistent state that is, for example, illustrated within
> Java's Thread-based objects within a connection pool. Can you using
> PHP 4+ and MySQL 4 utilize unique concurrent connections to the very
> same MySQL database instance?[/color]

Actually, even flat files are pretty hard to lock across multiple requests
in PHP :-p

I don't know a whole lot about Java, but the method you described doesn't
sound right to me. You don't use a synchronization object in the application
layer to protect a resource in the database layer. I mean, what if there're
more than one app server accessing the database? The locking mechanism
should be implemented in the database itself. To grant access to a user,
just set a ownership column in the table to the user id. To release a
resource, set the column to null.

re: PHP and Threading - is it possible?

With none of the languages I have ever worked with, including PHP, has the
idea of multiple clients sharing the same database connection ever arisen.
Each request has its own connection, and when that request is complete the
connection is closed. The exception to this is persistent connections, but
even then one connection can only service requests from one client.

What you are describing may be relevant in Java, but it is irrelevant in
PHP.

--
Tony Marston

http://www.tonymarston.net


"comp.lang.php" <phillip.s.powell@gmail.com> wrote in message
news:1107974616.392844.189300@g14g2000cwa.googlegr oups.com...[color=blue]
> Does your 25+ years of programming and "first come first served"
> solution involve connection pools and NOT flat files as you are
> implying.?? I'm not working with flat files in this case but with the
> need for a persistent state that is, for example, illustrated within
> Java's Thread-based objects within a connection pool. Can you using
> PHP 4+ and MySQL 4 utilize unique concurrent connections to the very
> same MySQL database instance?
>
> Phil
>[/color]

re: PHP and Threading - is it possible?

comp.lang.php wrote:[color=blue]
> That is a major fundamental problem then. Because if what you say is
> true, then in order to set up a persistent environment to handle
> potential collisions, one would have to have the PHP equivalent of
> BEA/WebLogic as an application server running alongside your
> application to ensure an ordered persistent-state environment, which
> if I remember there is nothing out there unlicensed open-source in
> PHP-dom, if wrong, point me in the right direction, please.[/color]

When working with PHP you should think it's way instead of forcing it to do
things it was not intended to. PHP is a good language for Web development
because it's philosophy closely mirrors the way the Web works; most other
languages have to adapt themselves somehow.

HTTP is a stateless protocol: when you load a HTTP response/page, which
gives you a state that was on the server the moment it was sent from there,
you have no idea what happens on the server -- the state there might
completely change and you and your browser will have no clue about it.

Consider a simple Web page (ie. no programming involved), and this scenario:
you open the page, say mypage.html, from my Web server, and while you're
reading it I delete it on the server. Although it exists no more (ie. its
state has changed), you still can see it until you try to load it again (or
even then for some time, depending on your browser's caching settings).

PHP is basically, as its new name nicely sums, a hypertext preprocessor:
when you request a HTTP address which calls a PHP script, it does nothing
else but preparing the output which will be sent by the server to your
browser. Historically, PHP is a simple procedural language, and each time
you call a script it executes anew, parsing and interpreting each
instruction one by one. There is no way -- and originally there was no
need -- to keep variables and its states in permanent memory, since most of
the time all persistent data was in databases or files (PHP has an excellent
mechanism to dynamically load and execute other PHP files, which are then
executed as if a part of the original script).

Through its evolution, PHP has gained various advanced features such as OOP,
but its essence -- it being the typical scripting language -- has remained
the same. With PHP there is no compile-time, everything is parsed and
evaluated only on run-time; and as it has no strong types, it is one of the
most dynamic languages in use: you can dynamicaly include libraries, assign
values or even load interpreter modules, or even such "perversions" like
variable variables, where you can decide which variable will be accessed (or
function/method called) by constructing its name dynamically.

Anyway, one should have in mind the specifics of the language working with,
regardless of which language it is. Basically, everything is possible with
every language: I have seen procedural applications written in Java (one
class, one main() method), as well as PHP OO bloatware with a hundred lines
of code and a separate template meta-language just for a simple Web site
(even without database!). So, when working in PHP you should think in PHP,
and ask more experienced programmers how to solve various issues (which
often turn out to be no issues at all).

Berislav

re: PHP and Threading - is it possible?

Thanx for a very comprehensive breakdown of the scope of PHP vs the
scope of having to work with persistent states.

What I am looking into would obviously have to be outside of PHP for
the solution, concentrating more with MySQL with table locking and
prioritizing transactional SQL statements. Might not be the best route
but I think that's all I have to work with at the moment.

Thanx again!

Phil

re: PHP and Threading - is it possible?

Perhaps if you rephrase your Original Post explaining exactly what you
are trying to accomplish, somebody might be able to explain how to
accomplish it in PHP.

All of the "issues" you have raised so far about collisions in your
database inserts,updates,and deletes should be resolvable through the
use of transactions.

If you have a specific situation in mind that you think cannot be
resolved, it would be helpful if you could provide an outline of the
steps you are stuck on and maybe then someone will think of a way to
successfully complete those steps in PHP.

re: PHP and Threading - is it possible?

comp.lang.php wrote:[color=blue]
> Thanx for a very comprehensive breakdown of the scope of PHP vs the
> scope of having to work with persistent states.
>
> What I am looking into would obviously have to be outside of PHP for
> the solution, concentrating more with MySQL with table locking and
> prioritizing transactional SQL statements. Might not be the best
> route but I think that's all I have to work with at the moment.[/color]

A brief, but strong suggestion: use ADOdb for database access:
http://adodb.sourceforge.net/

Berislav