Re: PHP 5 and Shared objects
| From: | Salah Faya | Date: | Tue, 22 Apr 2003 06:13:08 +0000 |
| Subject: | Re: PHP 5 and Shared objects | ||
| References: | 1 2 3 4 5 6 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-144765@lists.php.net to get a copy of this message | ||
Hi Greg,
Thanks for the clarification.
My concern in my question is about the performance and the machine
resources, I thought that keeping the object alive while session is on will
use less memory and computer resources compared to what may happen when
thousands of requests for the same application files which need the same
object:
1- currently, on every request the script is gonna create the object.. so
1000 x Object creation + Object destruction (including making db
connections, files and etc)
2- in my opinion, on the first request the object is being created once, and
in the other 999 request it's just the object is being used not recreated,
and get destructed when the session/s is closed, logically the second way is
gonna use less computer resources?
----- Original Message -----
From: "Greg Beaver" <greg@chiaraquartet.net>
To: "Salah Faya" <salah@e-touch.ws>
Cc: <php-general@lists.php.net>
Sent: Monday, April 21, 2003 11:51 PM
Subject: [PHP] Re: PHP 5 and Shared objects
> Hi Salah,
>
> Imagine this scenario: you create an object. PHP saves it somewhere so
> that only a handle need be passed back. The session that the object
> belongs to is stored. No one accesses the session for 2 days. Where
> was the object during those 2 days? Taking up memory? This would be
> very inefficient use of resources and lead to a MS Windows-esque
> resource crash. Serialization is the only way to preserve an object
> after program termination. PHP scripts do not sit in memory cycling the
> way that GUI applications do. They work more like old DOS commands
> (excepting php-gtk, which doesn't need serialization at all to keep
> objects). Destructors should be called at the end of scripts. If an
> object opens a database connection, the destructor that closes this
> connection should be called when the script is concluded. If I
> understand what you mean by auto-loading, auto-loading is simply an
> automation of serialization.
>
> There is no detectable difference between a serialized object and the
> original object, why would you need to keep it alive? If you're
> concerned about what happens when an object serializes, you might
> benefit from reading about magic methods__sleep() and __wakeup()
>
> http://www.php.net/manual/en/language.oop.magic-functions.php
>
> The new object model removes the need to use the & operator like
> $myobject = &$thatobject as objects will always be passed by handle
> *when in memory*. This is still great news, as anyone who has tried to
> do a linked list implementation or parent->child->parent linking in php
> 4 knows about.
>
> Regards.
> Greg
> --
> phpDocumentor
> http://www.phpdoc.org
>
> Salah Faya wrote:
>
> >Eventhough after php 5? I thought may be PHP 5 and the new object model
will
> >stop the need-to-serialize
> >imagine my object class has a destructur function.. that means it's gonna
be
> >called between files in same session!
> >and what about the autoloading function and etc?
> >
> >----- Original Message -----
> >From: "Greg Beaver" <greg@chiaraquartet.net>
> >To: <php-general@lists.php.net>; "Salah Faya" <salah@e-touch.ws>
> >Sent: Monday, April 21, 2003 11:29 PM
> >Subject: [PHP] Re: PHP 5 and Shared objects
> >
> >
> >
> >
> >>The object itself is being serialized and re-created. You can read
> >>about how sessions affect objects at:
> >>
>
> >>>>http://www.php.net/manual/en/language.oop.serialization.php
> >>
> >>PHP is still cool, don't be dismayed :)
> >>
> >>Regards,
> >>Greg
> >>
> >>Salah Faya wrote:
> >>
> >>
> >>
> >>>What I meant is with PHP5 objects aren't treated as
associated-variables
> >>>
> >>>
> >so
> >
> >
> >>>we don't have to serialize them, do we? so when I share an object over
> >>>
> >>>
> >some
> >
> >
> >>>session the object itself will actually stay alive and only the
> >>>
> >>>
> >resource-id
> >
> >
> >>>will be passed from file to file trhough same session, in other words
the
> >>>object is not being recreated while keeping its resource-id in a
> >>>
> >>>
> >registered
> >
> >
> >>>session variable, or I'm wrong?
> >>>
> >>>About the global object, it could be a security risk if the programmer
is
> >>>gonna use it badly (u r right)
> >>>
> >>>----- Original Message -----
> >>>From: "Greg Beaver" <greg@chiaraquartet.net>
> >>>To: "Salah Faya" <salah@e-touch.ws>
> >>>Cc: <php-general@lists.php.net>
> >>>Sent: Monday, April 21, 2003 11:05 PM
> >>>Subject: Re: PHP 5 and Shared objects
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>This is already possible in php 4. However, both file1.php and
> >>>>file2.php must begin with a session_start() call.
> >>>>
> >>>>A global object (common to all sessions) is a big security risk, I
would
> >>>>be surprised if it is considered a feature by the php team. You can
> >>>>simulate such a thing yourself, by using a database, or a file on the
> >>>>server backend that contains the serialized contents of the object,
and
> >>>>retrieve them in the beginning of each file.
> >>>>
> >>>>Regards,
> >>>>Greg
> >>>>--
> >>>>phpDocumentor
> >>>>http://www.phpdoc.org
> >>>>
> >>>>Salah Faya wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>As I've understood that PHP5 OOP will allow us to use a session-level
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>shared
> >>>
> >>>
> >>>
> >>>
> >>>>>objects smoothly, as in example:
> >>>>>
> >>>>>- file1.php
> >>>>>session_register('myObj');
> >>>>>$myObj = new myClass(2003);
> >>>>>$x = $myObj->year; // returns 2003
> >>>>>header('location: file2.php?PHPSESID='.session_id());
> >>>>>
> >>>>>- file2.php
> >>>>>if (isset($_SESSION['myObj'])) {
> >>>>> $myObj=$_SESSION['myObj'];
> >>>>> echo $myObj->year; // should also return 2003
> >>>>>}
> >>>>>
> >>>>>am I right? please correct me
> >>>>>
> >>>>>And if that's correct, is there a way to make a global object over
all
> >>>>>sessions (immortal object)? can this be a good feature to request?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
>