Edit report at http://bugs.php.net/bug.php?id=19694&edit=1
ID: 19694 Updated by: [email protected] Reported by: citd at mediaways dot net Summary: Persistent Global Variable -Status: Open +Status: Bogus Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: N/A PHP Version: 4.2.3 Block user comment: N Private report: N New Comment: PHP has a shared-nothing architecture on purpose. Adding global variables introduces locking issues, issues when scaling to multiple machines etc. apc_store()/apc_fetch() or memcache as well as others provide solutions depending on your environment and needs. Previous Comments: ------------------------------------------------------------------------ [2004-09-07 19:38:13] [email protected] By the way, if it is just read-only config file key/value type stuff you are worried about, you can use cfg_get_var() to read custom .ini directives that will only be read on startup. With the new --with-config-file-scan-dir mechanism you can even configure a directory that will be scanned for ini files, so every application that needs config entries can simply drop their config ini file in that dir and the configuration will be read once on server startup. ------------------------------------------------------------------------ [2004-09-07 17:39:35] [email protected] The various opcode caches tend to implement this. mmcache and ZPS have ways to do this easily. And I will be submitting a patch to pecl/apc to support this as well shortly. That is, you can do: $var = apc_fetch('var'); And: apc_store('var',$var); We definitely don't want PHP to require a standalone marshalling process as someone suggested and as someone else suggested, no, the $_SESSION code is nothing like what would be needed for this. The main argument against using something like this is that your horizontal scalability is destroyed if you use it incorrectly. Ideally you want to architect your solution such that every request is sandboxed from every other so that you can handle an entire browsing session on any of dozens of servers behind a load balancer, for example. If you store state on a single machine like this, much like many Java apps do by storing state in the JVM, then you have a scalability nightmare on your hands. ------------------------------------------------------------------------ [2004-09-07 15:50:17] jon_obuchowski at terc dot edu I agree that a persistent variable functionality would be useful; however, this does require an additional level of configuration to allow ISPs soem leeway in how this is deployed; a) availabilty of feature AT ALL determined by configuration b) separate scopes for different applications (as several may be running on the same server and there needs to be some way to prevent collision); these scopes may be determined by name (low inter-application security), automatically by domain/URL path (higher security) or by some other means c) timeout periods (i.e. how often the application variables need to be refreshed) need to be determined on a per-server, per-application basis d) some sort of locking mechanism to prevent corruption issues during writing (assuming that multiple concurrent PHP requests have similar shared-memory issues to concurrent threads); this could be automatic and/or manual, depending on performance needs... ------------------------------------------------------------------------ [2004-03-26 14:17:13] hans at deragon dot biz 2004 and still nothing showing up for this issue. I am a newbie, but even I (less than one month of PHP experience) understand the importance of this issue. One could do something with shared memory and msession, but these solutions are overkill for small projects (and shared memory does not work on Windows). What we need is a simple global array named $_PERSISTENT. Anything stored in this array lives until unset or the server goes down. And as for the implementation, can't this be done easily? I mean, $_SESSION exists already and the only difference between $_SESSION and $_PERSISTENT is that $_SESSION is associated with a session (cookie or URL based). Just reuse the same code for $_SESSION, but without the user association code and voilà , a new feature is born. $_PERSISTENT would be so intuitive to use to newbies, as $_SESSION is. ------------------------------------------------------------------------ [2003-02-20 12:29:50] okapi at yahoo dot com I'm suprised why something along these lines isn't incorporated into PHP such that there's an application process that could handle application scope variables (and query caching). It seems this kind of issue would make it match up better with ASP and Cold Fusion. Is anyone aware of such an effort? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=19694 -- Edit this bug report at http://bugs.php.net/bug.php?id=19694&edit=1
