FAQ
Jonathan,

Thanks for the reply. Actually, my question was not a
"how to use", but definitely a "what are you doing?"
intended for the PHP authors (i.e. the Zend folks).

Logging is a great example of what I'd like to do, but
won't work in the current PHP5 implementation. If you
write a Logger class as a singleton, and a page makes
10 calls to the logger, then sure, those 10 calls will
use the same instance of Logger. But if there are say
10 pages in a users' progression, then you'd get 10
singletons created just for that user (thereby not
actually being a singleton at all). And if there were
100 concurrent users, there would be 100*10 instances
of Logger created, 100 at the same time--definitely
not a singleton.

No other languages behave this way (not Java or C# for
sure).

Thanks for the pointer to that other framework.

Dave

--- Jonathan Arkell wrote:
Hi Dave

I noticed your question on the php.internals mailing
list, and I wasn't
sure if you were going to get a reply because you
were asking a quesiton
about developing WITH php, rather then developing
php itself, which is
what the internals list is for.

At any rate, the answer to your question is: You
are correct, there
classes are loaded and unloaded on each page
request.

There is actually quite a bit of use in static
members, especially when
you stop thinking in terms of page-requests, and
more in terms of full
blown web applications. Think of it this way, it's
really nice to just
have a logging singleton object (for instance) that
you can
getInstance(); of every time you need access to a
logging object,
instead of having to pass its reference around.

However, there is a project that does what you want.
SRM
(http://www.vl-srm.net). It is a persistant object
repository. Your
Foo Class is defined and executed on the SRM server,
and when your
webserver gets a request, you write a little script
to make a request
for the Foo object from the SRM server. So the Foo
objet is persisitant
across requests.
http://www.vl-srm.net/doc/design.graphic.php shows
you
what is going on here.

Anyway, there you go, I hope that helps.

--
,-------. The Cute Grim Floating Skull of
Hello Cthulu Says
/ | | \
/ _ ^ _ \ Listen To Crazy Shaman Techno
\_/ }|||{ \_/
http://jonny.sanriowasteland.net
'^"^`
I'm Jonnay!

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

Search Discussions

  • Dave Peckham at Feb 16, 2004 at 6:13 pm
    Hi all,

    My initial response to Jonathan has me thinking more
    about this, and a higher level. I guess I want to hear
    from the Zend guys about their intentions of PHP as an
    app server. IMHO, that's the right direction.

    For example, when PHP is loaded by the web server,
    it's only loaded once, and it should keep track of all
    the classes that get loaded, and only load them once
    (unless the file changes, say). Static variables
    should apply to the server scope (classloader). The
    way it stands right now, if all the classes are
    essential unloaded after each request, then we're
    still really close to the CGI paradigm. If I have
    10,000 users who each use 10 pages per session, why do
    I need to load the "Foo" class 100,000 times?

    Zend guys, what are your thoughts? Was this concept
    considered and rejected? Your thought process and
    direction are important to my technology choice.

    Thanks,
    Dave

    __________________________________
    Do you Yahoo!?
    Yahoo! Finance: Get your refund fast by filing online.
    http://taxes.yahoo.com/filing.html
  • Marcus Boerger at Feb 16, 2004 at 7:41 pm
    Hello Dave,

    seems like you misunderstood the basic concept of
    PHP - it is stateless. That means that no information
    is propagated from one script execution to another -
    or in other words we have neitehr an application server
    nor persistent variables.

    regards
    marcus

    Monday, February 16, 2004, 7:13:17 PM, you wrote:
    Hi all,
    My initial response to Jonathan has me thinking more
    about this, and a higher level. I guess I want to hear
    from the Zend guys about their intentions of PHP as an
    app server. IMHO, that's the right direction.
    For example, when PHP is loaded by the web server,
    it's only loaded once, and it should keep track of all
    the classes that get loaded, and only load them once
    (unless the file changes, say). Static variables
    should apply to the server scope (classloader). The
    way it stands right now, if all the classes are
    essential unloaded after each request, then we're
    still really close to the CGI paradigm. If I have
    10,000 users who each use 10 pages per session, why do
    I need to load the "Foo" class 100,000 times?
    Zend guys, what are your thoughts? Was this concept
    considered and rejected? Your thought process and
    direction are important to my technology choice.
    Thanks,
    Dave
    __________________________________
    Do you Yahoo!?
    Yahoo! Finance: Get your refund fast by filing online.
    http://taxes.yahoo.com/filing.html



    --
    Best regards,
    Marcus mailto:helly@php.net
  • Andi Gutmans at Feb 17, 2004 at 8:49 am

    At 10:13 AM 2/16/2004 -0800, Dave Peckham wrote:
    Hi all,

    My initial response to Jonathan has me thinking more
    about this, and a higher level. I guess I want to hear
    from the Zend guys about their intentions of PHP as an
    app server. IMHO, that's the right direction.

    For example, when PHP is loaded by the web server,
    it's only loaded once, and it should keep track of all
    the classes that get loaded, and only load them once
    (unless the file changes, say). Static variables
    should apply to the server scope (classloader). The
    way it stands right now, if all the classes are
    essential unloaded after each request, then we're
    still really close to the CGI paradigm. If I have
    10,000 users who each use 10 pages per session, why do
    I need to load the "Foo" class 100,000 times?

    Zend guys, what are your thoughts? Was this concept
    considered and rejected? Your thought process and
    direction are important to my technology choice.
    PHP is pretty much a stateless language. If you want to keep a state you're
    going to have to serialize/unserialize to your harddisk or DB. There have
    been attempts at creating something similar to an app server such as srm
    but they never really took off. In any case, "app server" is quite a
    general concept and I could argue that Apache & PHP together are an App
    Server.

    Anyway, if you really need to persist data/variables across requests, there
    are ways to do it (if it's per-Apache process it's even easier) but not
    quite as simple as leaving an object floating around in main memory between
    requests.

    Andi
  • Dave Peckham at Feb 17, 2004 at 9:15 am
    Andi (and all),

    You are completely missing my point. I'm not looking
    for stateful storage of user variables. If a page
    creates an instance of the Person class and assigns it
    to $dave, then I expect $dave to go out of scope (and
    permanently disappear) at the end of the page request
    lifecycle--just like I expect a variable assigned
    inside a function to go out of scope when the function
    exits.

    What I want the Zend engine to do is recognize that
    the Person class need not be loaded and parsed on
    every single page. The CLASS (not instances of) should
    be managed (i.e. loaded) only once per server.
    Therefore, static variables in the class would in fact
    be scoped at the classloader level.

    Then, all the pages that use Person class do not have
    to parse that class on every page request. This would
    be 1) a major performance boost, and 2) enable *real*
    use of static members (i.e. for proper implementation
    of the Singleton pattern).

    Am I being clear now?

    You know, it's really encouraging to see that the
    object syntax in PHP5 is so robust. But if I can't use
    the robust syntax to build robust applications, then
    what's the point?

    Consider this... there are lots of PHP developers who
    get started building relatively simple sites. Over
    time, those sites become more complex. At some point,
    the requirements of the project (customer) dictate
    more advanced technology. If you were to start
    including the features I've described, you could
    prolong the relevancy of PHP in these solutions. In
    other words, what's the growth path of PHP developers
    and PHP solutions as needs become more complex?

    Thanks,
    Dave


    --- Andi Gutmans wrote:
    At 10:13 AM 2/16/2004 -0800, Dave Peckham wrote:
    Hi all,

    My initial response to Jonathan has me thinking more
    about this, and a higher level. I guess I want to hear
    from the Zend guys about their intentions of PHP as an
    app server. IMHO, that's the right direction.

    For example, when PHP is loaded by the web server,
    it's only loaded once, and it should keep track of all
    the classes that get loaded, and only load them once
    (unless the file changes, say). Static variables
    should apply to the server scope (classloader). The
    way it stands right now, if all the classes are
    essential unloaded after each request, then we're
    still really close to the CGI paradigm. If I have
    10,000 users who each use 10 pages per session, why do
    I need to load the "Foo" class 100,000 times?

    Zend guys, what are your thoughts? Was this concept
    considered and rejected? Your thought process and
    direction are important to my technology choice.
    PHP is pretty much a stateless language. If you want
    to keep a state you're
    going to have to serialize/unserialize to your
    harddisk or DB. There have
    been attempts at creating something similar to an
    app server such as srm
    but they never really took off. In any case, "app
    server" is quite a
    general concept and I could argue that Apache & PHP
    together are an App
    Server.

    Anyway, if you really need to persist data/variables
    across requests, there
    are ways to do it (if it's per-Apache process it's
    even easier) but not
    quite as simple as leaving an object floating around
    in main memory between
    requests.

    Andi

    __________________________________
    Do you Yahoo!?
    Yahoo! Finance: Get your refund fast by filing online.
    http://taxes.yahoo.com/filing.html
  • Stig S. Bakken at Feb 17, 2004 at 9:56 am
    Hi Dave,

    I think I see what you're saying. Static class variables are associated
    with the class, if the class persists between requests, so should its
    static variables.

    In the Java model of operation, it's natural to think in these terms, as
    the Java web server or application server is self-sustained, in the
    sense that it completely manages its own resources between requests. A
    static class variable used by a singleton could contain an instance that
    would be accessible without loading the class and creating the instance
    again. This is what you mean, right?

    The typical PHP model is very different (I say typical because you CAN
    implement a model similar to Java's with PHP too, it is just not how
    people use PHP); PHP is request/response driven, and except for
    persistent resources, no run-time-generated data is kept between
    requests. This is a very fundamental feature of PHP/Zend, and makes PHP
    very robust, flexible and scalable.

    If PHP kept run-time data between requests, a lot of the safety net PHP
    provides (auto-closing resources and auto-freeing memory at the end of
    requests) would be lost. It would make integration with server backends
    (such as Apache) more complex, and it would make it harder to scale PHP
    applications because you introduce state that assumes every request ends
    up on the same server (or you need a really fast rpc mechanism).

    I think the approach most PHP developers would take (if they indeed
    needed this feature) would be to serialize the singleton object and
    deserialize(clone) it on subsequent requests.

    Anyway, to ease the pain, have you looked at any of the available PHP
    code caches, such as APC, ZendAccellerator (commercial) or phpa?

    http://apc.communityconnect.com/ (or simply run "pear install apc")
    http://www.zend.com/
    http://www.php-accelerator.co.uk/

    AFAIK none of these are ported to PHP 5 yet, I know APC and
    ZendAccelerator will be (never used phpa myself).

    All of these basically keep the parsed representation of code in shared
    memory between requests. It doesn't give you persistent class statics,
    but at least the request startup is much lower.

    - Stig
    On Tue, 2004-02-17 at 10:15, Dave Peckham wrote:
    Andi (and all),

    You are completely missing my point. I'm not looking
    for stateful storage of user variables. If a page
    creates an instance of the Person class and assigns it
    to $dave, then I expect $dave to go out of scope (and
    permanently disappear) at the end of the page request
    lifecycle--just like I expect a variable assigned
    inside a function to go out of scope when the function
    exits.

    What I want the Zend engine to do is recognize that
    the Person class need not be loaded and parsed on
    every single page. The CLASS (not instances of) should
    be managed (i.e. loaded) only once per server.
    Therefore, static variables in the class would in fact
    be scoped at the classloader level.

    Then, all the pages that use Person class do not have
    to parse that class on every page request. This would
    be 1) a major performance boost, and 2) enable *real*
    use of static members (i.e. for proper implementation
    of the Singleton pattern).

    Am I being clear now?

    You know, it's really encouraging to see that the
    object syntax in PHP5 is so robust. But if I can't use
    the robust syntax to build robust applications, then
    what's the point?

    Consider this... there are lots of PHP developers who
    get started building relatively simple sites. Over
    time, those sites become more complex. At some point,
    the requirements of the project (customer) dictate
    more advanced technology. If you were to start
    including the features I've described, you could
    prolong the relevancy of PHP in these solutions. In
    other words, what's the growth path of PHP developers
    and PHP solutions as needs become more complex?

    Thanks,
    Dave


    --- Andi Gutmans wrote:
    At 10:13 AM 2/16/2004 -0800, Dave Peckham wrote:
    Hi all,

    My initial response to Jonathan has me thinking more
    about this, and a higher level. I guess I want to hear
    from the Zend guys about their intentions of PHP as an
    app server. IMHO, that's the right direction.

    For example, when PHP is loaded by the web server,
    it's only loaded once, and it should keep track of all
    the classes that get loaded, and only load them once
    (unless the file changes, say). Static variables
    should apply to the server scope (classloader). The
    way it stands right now, if all the classes are
    essential unloaded after each request, then we're
    still really close to the CGI paradigm. If I have
    10,000 users who each use 10 pages per session, why do
    I need to load the "Foo" class 100,000 times?

    Zend guys, what are your thoughts? Was this concept
    considered and rejected? Your thought process and
    direction are important to my technology choice.
    PHP is pretty much a stateless language. If you want
    to keep a state you're
    going to have to serialize/unserialize to your
    harddisk or DB. There have
    been attempts at creating something similar to an
    app server such as srm
    but they never really took off. In any case, "app
    server" is quite a
    general concept and I could argue that Apache & PHP
    together are an App
    Server.

    Anyway, if you really need to persist data/variables
    across requests, there
    are ways to do it (if it's per-Apache process it's
    even easier) but not
    quite as simple as leaving an object floating around
    in main memory between
    requests.

    Andi

    __________________________________
    Do you Yahoo!?
    Yahoo! Finance: Get your refund fast by filing online.
    http://taxes.yahoo.com/filing.html
    --
    "Nearly all men can stand adversity, but if you want to test a man's
    character, give him power." - Abraham Lincoln
  • Adam Bregenzer at Feb 17, 2004 at 10:30 am

    On Tue, 2004-02-17 at 04:55, Stig S. Bakken wrote:
    Hi Dave,

    I think I see what you're saying. Static class variables are associated
    with the class, if the class persists between requests, so should its
    static variables. [snip]
    All of these basically keep the parsed representation of code in shared
    memory between requests. It doesn't give you persistent class statics,
    but at least the request startup is much lower.
    Great response, you saved me a lot of typing. :)

    To add one thing, I have code that I use to easily persist an object
    across a session, additionally it can save the class's static properties
    (hacked into PHP4[1]). With this and my implementation of the singleton
    pattern I am able to persist a singleton throughout a session. It's not
    exactly what you are talking about but can be just as useful.
    Additionally you can use a database or shared memory to implement global
    variables and save objects/static variables/whatever into them. Of
    course, once you have variables available to multiple instances of PHP
    you will have to deal with locking issues.

    Regards,
    Adam

    [1] http://adam.bregenzer.net/php/static_class_properties

    --
    Adam Bregenzer
    adam@bregenzer.net
    http://adam.bregenzer.net/
  • Derick Rethans at Feb 17, 2004 at 11:07 am

    On Tue, 17 Feb 2004, Adam Bregenzer wrote:

    Great response, you saved me a lot of typing. :)

    To add one thing, I have code that I use to easily persist an object
    across a session, additionally it can save the class's static properties
    (hacked into PHP4[1]). With this and my implementation of the singleton
    pattern I am able to persist a singleton throughout a session. It's not
    exactly what you are talking about but can be just as useful.
    Additionally you can use a database or shared memory to implement global
    variables and save objects/static variables/whatever into them. Of
    course, once you have variables available to multiple instances of PHP
    you will have to deal with locking issues.
    I don't want to plug anything, but have a look at www.vl-srm.net; it
    tries to achive this (note: site is a bit outdated).

    Derick
  • Adam Bregenzer at Feb 17, 2004 at 3:49 pm

    On Tue, 2004-02-17 at 06:07, Derick Rethans wrote:
    I don't want to plug anything, but have a look at www.vl-srm.net; it
    tries to achive this (note: site is a bit outdated).
    You don't have to plugin anything, you can do it in PHP and the data
    storage method of your choice. Keep in mind that srm is a PHP extension
    and therefore less portable than just using PHP code. Srm's design is
    certainly much more robust than what I have below, but here's a basic
    pseudo code example of global variables using shared memory and very
    simple locking. You could extend this to also save and restore static
    variables in objects.

    function retrieveGlobalVar($var_name) {
    if (shmGetVal($var_name . '-lock') == '0') {
    // grab variable from storage
    $val = unserialize(shmGetVal($var_name));
    // Lock variable automatically
    lockGlobalVar($var_name);
    // return variable
    return $val;
    } else {
    // Locked
    return null;
    }
    }
    function saveAndReleaseGlobalVar($var_name, $var) {
    // save variable
    shmSetVal($var_name, serialize($var));
    // Unlock variable automatically
    unlockGlobalVar($var_name);
    }
    function deleteGlobalVar($var_name) {
    // Delete variable
    shmDeleteVal($var_name);
    // Delete variable's locking value
    shmDeleteVal($var_name . '-lock');
    }
    function lockGlobalVar($var_name) {
    // mark variable as locked
    shmSetVal($var_name . '-lock', '1');
    }
    function unlockGlobalVar($var_name) {
    // mark variable as unlocked
    shmSetVal($var_name . '-lock', '0');
    }

    Regards,
    Adam

    --
    Adam Bregenzer
    adam@bregenzer.net
    http://adam.bregenzer.net/
  • Derick Rethans at Feb 17, 2004 at 9:39 am

    On Tue, 17 Feb 2004, Andi Gutmans wrote:

    PHP is pretty much a stateless language. If you want to keep a state you're
    going to have to serialize/unserialize to your harddisk or DB. There have
    been attempts at creating something similar to an app server such as srm
    but they never really took off.
    Because SRM didn't really work :) I am working on it again now though.
    In any case, "app server" is quite a general concept and I could argue
    that Apache & PHP together are an App Server.
    I agree there.

    regards,
    Derick

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 16, '04 at 5:56p
activeFeb 17, '04 at 3:49p
posts10
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase