Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70135 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65951 invoked from network); 14 Nov 2013 21:34:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Nov 2013 21:34:10 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:40368] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/C2-53459-1D145825 for ; Thu, 14 Nov 2013 16:34:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 708241402EC; Thu, 14 Nov 2013 16:34:06 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 0B6C614010E; Thu, 14 Nov 2013 16:34:05 -0500 (EST) Message-ID: <528541CD.1040706@sugarcrm.com> Date: Thu, 14 Nov 2013 13:34:05 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: Adam Harvey , "internals@lists.php.net" References: <5285390D.6000106@sugarcrm.com> <52853E69.5040104@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Session cache, lock and write From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I agree. > This behavior could be dangerous just like SQL without transaction. No, it is way, way more dangerous. SQL only changes the rows it touches, session saves the whole session. It would be as if every SQL statement would read whole database when you start the application, changed something and then wrote the whole database - even the data you never intended to touch - back to the disk, wiping out all the changes in all other tables other applications changed since you have read it. Unlike SQL, which operates only on small piece of data at a time usually, session writes the whole thing in one bunch. There is no partial reads in writes. So situation here is not even close to SQL - it is way worse. The frame of breakage is much larger and the breakage is practically guaranteed to occur. > It's dangerous, but if user know what they are doing, it could be safe and > application runs faster. This should be documented well. IMO. I don't think there's a user that knows that they are doing enough to use such thing (because that means they have to know exactly how every request in their app ever is serialized and what the exact timing of every request is, now and forever in the future, and I do not see how it is feasible). There might be ones that think they do, but that would be a dangerous delusion, and I don't think we should support it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227