Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53603 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22965 invoked from network); 27 Jun 2011 17:05:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jun 2011 17:05:29 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.27 out3.smtp.messagingengine.com Received: from [66.111.4.27] ([66.111.4.27:44524] helo=out3.smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 70/5D-47962-858B80E4 for ; Mon, 27 Jun 2011 13:05:29 -0400 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id B6AF4206D4 for ; Mon, 27 Jun 2011 13:05:26 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 27 Jun 2011 13:05:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=07wbfRuSSiBvR/EZ6hOg1csDe8g=; b=EX3ETNKB32TIHfvBEFqxyPWpzFlJM/makXpUMIr6ckDUea0wZtpZk6jCS5HmQfpdB7GAaHjoSwyt1xWUhddLDoODHKzh0Awsv4qL5sKd4NjM03seIDUQTpOb06UsGavAjsdlrjFm9uDmyrG5nlzRscmHQ1K1mCrL5h5Gp3lkvx4= X-Sasl-enc: etEXJL8sEMjDOwgp6zanXs6+Dy9F8wOJ1eTW/To8WiQy 1309194326 Received: from garfield.ad.palantir.net (unknown [209.41.114.202]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4EC7044075A for ; Mon, 27 Jun 2011 13:05:26 -0400 (EDT) Message-ID: <4E08B853.8000205@garfieldtech.com> Date: Mon, 27 Jun 2011 12:05:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: internals@lists.php.net References: <4E07FE98.9080002@garfieldtech.com> In-Reply-To: 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 6/27/11 11:01 AM, Arpad Ray wrote: > On Mon, Jun 27, 2011 at 5:00 PM, Arpad Ray wrote: >> On Mon, Jun 27, 2011 at 4:52 AM, Larry Garfield wrote: >>> 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... >> >> If the database object isn't manually cleaned up (all references to it >> are unset) then that will take place in the second stage of the >> request shutdown process, whereas the first stage is running the >> shutdown functions, so that shouldn't be an issue. >> >> The most common use case for the second argument is where the user >> already calls session_write_close() (probably in their own shutdown >> function) and doesn't reopen it - it's then useless for us to register >> and call our shutdown function. >> >> Regards, >> >> Arpad Ah, so the order at the end of the request would be: - Fire normal registered shutdown routines. - Fire session-close shutdown routine. - Call destructors on all objects still outstanding. That seems fine to me. --Larry Garfield