ID: 19694
Updated by: [EMAIL PROTECTED]
Reported By: citd at mediaways dot net
Status: Open
Bug Type: Feature/Change Request
Operating System: N/A
PHP Version: 4.2.3
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
[2002-10-02 03:16:56] citd at mediaways dot net
Thinking at Shared memory data-interchaning comes to my mind. (OK SSJS
can interchange data via the project-variable. But, at leat in our
project, i can't see the point for this.)
For our project a global and persistent variable is important for
SPPPPPEEEEEDDDDDD (and cost. We don't have to buy more
frontend-machines to compensate the performance losse of PHP compared
to SSJS). Having to parse the configuration for every request just
kills the performance.
------------------------------------------------------------------------
[2002-10-01 12:23:18] [EMAIL PROTECTED]
what about using shared memory?
http://www.php.net/manual/en/ref.sem.php
http://www.php.net/manual/en/ref.shmop.php
------------------------------------------------------------------------
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/19694
--
Edit this bug report at http://bugs.php.net/?id=19694&edit=1
