Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53593
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <4E07FE98.9080002@garfieldtech.com>
Date: Sun, 26 Jun 2011 22:52:56 -0500
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10
MIME-Version: 1.0
To: internals@lists.php.net
References: <BANLkTi=Kbbv_Vt9zb+e3faoUqUWekDr8Gw@mail.gmail.com>	<BANLkTikWE4xdJs7UnX3ZfcyVO3KrxP+jLg@mail.gmail.com>	<BANLkTinUPizFtNR2SeiCtsbwyVB2SUQUHQ@mail.gmail.com>	<BANLkTik6KaHhY+RvTYY5+DEphsGWrekPrA@mail.gmail.com>	<BANLkTi=PE_HVbbv6NtjAK=pCdtAdkTXTyw@mail.gmail.com> <BANLkTinAz-ZNK0SXVp_RNhkujUcFNgma6g@mail.gmail.com>
In-Reply-To: <BANLkTinAz-ZNK0SXVp_RNhkujUcFNgma6g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Object oriented session handlers
From: larry@garfieldtech.com (Larry Garfield)

On 06/25/2011 12:13 AM, Arpad Ray wrote:
> Hi,
>
> I've updated the patches again.
>
> The most significant change is that the shutdown function registers
> another shutdown function when it's called, to (almost) ensure that
> it's always the last one, and therefore user shutdown functions should
> always find the session available as expected. I'd especially
> appreciate feedback or improvements on this because it feels very
> hacky. One option is to add a separate hash of internal shutdown
> functions which run after the user shutdown functions, another is to
> add an element to the module entry, a la RSHUTDOWN, which gets run in
> between steps 1 and 2 in the shutdown process (see main.c:1632).
>
> I don't know what other uses there are for this, so I've stuck with
> the double shutdown function method in this patch. I'd also like to
> avoid complicating the vote on this patch with a tangential issue.
>
> I've added a second optional argument to
> session_set_save_handler($obj) which is true by default and indicates
> whether the shutdown function should be registered - this is so that
> users with their own manual shutdown procedure can disable the
> automatic approach. I think that most users will take advantage of the
> automatically registered shutdown function, but this lets those with a
> custom shutdown procedure handle the session shutdown within the
> lifetime of the script and save the slight overhead.
>
> http://spellign.com/patches/php-trunk-session-oo10.patch
> http://spellign.com/patches/php-trunk-session-oo10-tests.patch
>
> Regards,
>
> Arpad

I'm a bit confused.  If the session handler goes out of its way to 
ensure that it's the last thing to run, wouldn't that cause an issue if 
it tries to write session data after, say, the database connection 
object it wants to use has already been cleaned up?  Or is that the use 
case for the "do not register" parameter?  It seems like it would be a 
fairly common use case...

--Larry Garfield