I don’t think so. In a Servlet container objects might live beyond a request and could be accessed by a lot of other objects at the same time. This means you will have to handle concurrency problems which is not a trivial issue.
I agree, I think this will really change the way you write scripts. You have to be less sloppy to avoid having your script eat up all memory after 10 minutes, and your way of accessing data changes because your script is persistent.
sighs You should be coding less sloppily anyway… Memory consumption, CPU consumption - few PHP developers actually care about it even though they should.
Actually I didn’t talk about problems resolving from sloppy coding, but problems of concurrency.
You don’t have to care about concurrency in PHP because your script is executed only per request.
Imagine you’d have an object that exists beyond a request (for example stored in application context to speak in Java). Now two or more servlet scripts could manipulate this object at the same time (concurrently) and weird problems could occur, like lost updates (overwritten changes) for example. So you would have to synchronize access to this object (e.g. “lock” and “unlock” it).
That’s all stuff that you don’t have to care about in conventional PHP development (the only concurrency occurs within database access, but your rdbms will handle this for you).
I doubt concurrency in PHP would be very hard to implement (although a little tedious). An ‘application scope’ variable would be great - like the $_SESSION variable, but accessable to all PHP applications running on the same server. for exaxample:
application_register (‘users’);
$_APPLICATION[‘users’]++; // When the session starts
// TODO: implement logic
$_APPLICATION[‘users’]–; // And again when it ends
To deal with concurrency, you’d have to register variables independantly so that you you can assign a mutex to it, which solves the concurrency issue. I’m not sure how you’d be able to keep track of a mutex accross multiple processes (e.g. apache prefork), but it’d be trivial for the multi-threaded apache mode.
This could open up a large number of possibilities, like initializing a class that would normally take a long time to do (e.g. keeping oftenly used data from a database, or a list of concurrent clients). I’ll experement & see if I can hackup a quick implementation (dont expect anything soon).
Just my $0.02
ArrayAcces interface onto the Semaphore extension perhaps?
Something like…
class SharedMemoryArray implements ArrayAccess
{
protected $shm;
function __construct($pathname, $project) { $this->shm = ftok($pathname, $project); }
function offsetGet($key) { return shm_get_var($this->shm, $key); }
function offsetSet($key, $value) { return shm_put_var($this->shm, $key, $value); }
function offsetUnset($key) { return shm_remove_var($this->shm, $key); }
function offsetExists($key) { return @shm_get_var($this->shm, $key) !== FALSE && ...something...; }
function __destruct() { @shm_detach($this->shm); }
}
class Application extends SharedMemoryArray
{
function __construct() { parent::__construct($_SERVER['DOCUMENT_ROOT'], ..something..); }
}
$_APPLICATION = new Application();
Haven’t tried it, not sure it how well (if at all) it would work.
Would have some problems with offsetGet() not returning a reference I think.
And offsetExists() doesnt seem to have a natural equivalent shm_ function()
shm_get_var() returns FALSE and a warning when a $key doesnt exist.
It isn’t going to help with the concurrency problems, though may be a start.
Douglas
What about shm_aquire, that could help with concurrency issues
Unless i’ve mis-read the description, it seems to do the job.
Although tmpfs could be considered a viable option… serializing/deserializing the $_APPLICATION variable to the file (ala file based sessions) but with file locking?
Wouldn’t tmpfs be slower than using semaphores?
Another possibility could be sqlite using in memory (‘:memory:’) database, with the queries pre-prepared (turned into sqlites’ bytecode).
While true, that doesn’t mean you should go ahead and do something that’s going to use huge amounts of CPU, just because it’s not concurrent. Sloppyness still needs to be cleaned up.
PHP-GTK is concurrent and client side, makes perfect sense. Unfortunately it doesn’t make sense to run concurrent scripts on a server, as you have no idea when the person closes the application (browser). You’d be left with many open leads. DDoS’ing would be made that much easier.
I believe that’s exactly what this project is trying to do:
Although their project had a bunch of activity for about a month just over a year ago and appears to have stalled since then. Looked promising though.
I’m thinking of undertaking such an endeavor as the next phase of my new project (phpBeans, see the sig for details), as I think it would be very beneficial for PHP’s perception in the higher-end of businesses. I think it could also simplify several aspects of writing web apps in PHP, including installation (no Apache config any more), app writing, and interoperability between apps. It could also have big performance gains, as DB connections and other objects could be instantiated only once and reused for multiple requests.
Because of that last step though, writing an app for a servlet container would be a little different than for an “ordinary” framework.
Anyway, hope my $0.02 were worth it. 
Cheers,
Lux
The main difference between Java and PHP, imo, is that you can squeeze OO model whenever you want and obtain a result with PHP and it’s easier to install. You can do everything like the old-C manner : the famous procedural evil-noob manner.
If you do PHP code without using classes (or only for your DB access) … then you code like my old-father and you’re code will be difficult to maintain without your personal knowledge (this is the master flaw of all imo).
Look at productivity frameworks like Symfony or Zend. Everything is Object like in Java.
Servlet is not only abstractions and a bunch of Objects to make OO dev happy. It helps implementing maintainable and configurable code (trough XML or INI files for PHP).
To be very simplistic (passing by threading, application scope, etc…) servlets can be seen as a framework that makes relations between website paths like /index.php and an object class that implements everything your request need to do.
With that kind of architecture, MVC implementation is doable very very easily.
Last thing about the application scope. It’s like if you’re using a PECL extension like memcache to reduce Object instantations on every request. And doing things like this can make you save a lot of IO resources.
Hi.
You are replying to a thread which is more than 73 months old. If you want to start a new discussion, start a new topic
It’s Christmastime, not Halloween. Thread Necromancy is evil.
Arise foul thread and haunt the living… Mwa ha ha ha !!!