Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70131 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59916 invoked from network); 14 Nov 2013 21:19:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Nov 2013 21:19:42 -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.107 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.107 smtp107.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.107] ([108.166.43.107:60710] helo=smtp107.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2B/61-53459-D6E35825 for ; Thu, 14 Nov 2013 16:19:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 60DA998171; Thu, 14 Nov 2013 16:19:38 -0500 (EST) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id EF0B198113; Thu, 14 Nov 2013 16:19:37 -0500 (EST) Message-ID: <52853E69.5040104@sugarcrm.com> Date: Thu, 14 Nov 2013 13:19:37 -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> 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 think you've wrote this before I sent new mail. For files save handler, > when session.lock=Off, it will be > > open-and-lock -> read session data -> close-and-unlock -> > script executed > -> open-and-lock -> write session data -> close-and-unlock I don't think this is a very good idea, since what happens if somebody else changed the state while script was executing? That change would be killed by the write. The lock is not for writing, the lock is for data consistency between reading in writing. If you gave up the lock, you should not write afterwards because your data may be stale. > would not be a problem with write short circuit, since unchanged session > data is not written to session storage. User has to know what session > module is doing well to avoid problems, though. That's exactly the problem. Using this method would mean anything you write to a session can magically vanish and you wouldn't have any idea why, just because some other script was executing at the same time and have overwritten your data. "Read and never write" is OK, but read and then write without locking is very dangerous. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227