Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73210 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91383 invoked from network); 17 Mar 2014 10:36:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Mar 2014 10:36:34 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.217.182 mail-lb0-f182.google.com Received: from [209.85.217.182] ([209.85.217.182:43219] helo=mail-lb0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B2/91-17561-030D6235 for ; Mon, 17 Mar 2014 05:36:33 -0500 Received: by mail-lb0-f182.google.com with SMTP id n15so3462694lbi.41 for ; Mon, 17 Mar 2014 03:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Kb14ZoaE5A1qxRiIDNou93Efq2+o+to7nbWwBGnHc4s=; b=gRvRO2mclYYF16J8gJ2SgBNLh4PkA4mogwWG54XN+F54TfT9DZbLVUlclo0jTpQ34Q hm+1S7Dp8gC8jY4HVEcRMx7TOadrhrWfswJI057j9jr9H9XBR6UuimzKBfJ6lLwut7c7 7lBrzNMxwYpe3u8IGAiPUfJM8HBC51wgkp9+yliA37CnbFJ7ualXYYIjqDRNvI6Lg1KB AkJn9D+mbB85Fny5YYwtVLO4s9Wwg8vk1IY2690wsqDLIIDgs7SQAkU4UnhSWgcoWqSs CojoMchUgQTkJetEc34W2KDAR2h5Eo1jTjuMJA8hMGwNPk7w+XMXKFv6hesgjw+412gQ FUNw== X-Received: by 10.112.209.5 with SMTP id mi5mr7981512lbc.30.1395052589728; Mon, 17 Mar 2014 03:36:29 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.205.73 with HTTP; Mon, 17 Mar 2014 03:35:49 -0700 (PDT) In-Reply-To: References: <5324FE40.1070704@sugarcrm.com> <532603A0.8060802@sugarcrm.com> Date: Mon, 17 Mar 2014 19:35:49 +0900 X-Google-Sender-Auth: Xty6HGK19F69-4wnR_ppjgNPMwM Message-ID: To: Andrey Andreev Cc: Stas Malyshev , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11c25d480dccb704f4cafe6d Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11c25d480dccb704f4cafe6d Content-Type: text/plain; charset=UTF-8 Hi all, On Mon, Mar 17, 2014 at 6:57 PM, Andrey Andreev wrote: > On Mon, Mar 17, 2014 at 11:31 AM, Yasuo Ohgaki wrote: > > On Mon, Mar 17, 2014 at 6:14 PM, Andrey Andreev > wrote: > >> Is there a default SessionHandler::update() method? If yes, how is > >> that handled? That's supposedly just exposing the internal API and a > >> user can choose whether to override one or many methods. But if all of > >> them are overriden, how do you know it uses the same storage at all? > >> And what if an existing userland handler already has an update() > >> method that does something completely different? > > > > > > There is dummy function for validateSid() and update(). > > Both returns true always. > > > > If save handler (regardless of user or C) does not implement its own > > update(), > > then update() will not be called, instead write() is called. > > To do that, address of the dummy function is compared. > > Ok, so why is 'lazy_write' an option at all then? I don't see a reason > why it shouldn't be the default and even mandatory behavior. > I would like to make 'lazy_write' default to TRUE, since there would not be 'unsafe_lock'. I wouldn't try to add 'unsafe_lock' anymore. It's safe to make 'lazy_write' default to TRUE. 'lazy_write' needs a little memory, but it's session. Session data would be small enough for almost all apps and memory is cheap these days. (Note: I've implemented 'lazy_write' by using MD5 hash at first, but benchmark revealed simple store and string compare is much faster. It's saving loaded session data and compare to check modification with new patch.) Any objection/comment make this default to TRUE or automatically apply 'lazy_write'? I think automatically applying 'lazy_write' is good choice. >> The devil is in the details and these details aren't explained > >> anywhere, that's why I'm concerned. > > > > > > Currently implemented save handlers work as it is now both user and C. > > > >> Btw, this should probably be called updateTimestamp() instead of > >> update(), for userland at least. write() vs. update() can be somewhat > >> confusing. > > > > > > This could be changed. Better name is always good. > > Well, there you go - updateTimestamp() is a better name. ;) I thought of similar name. I choose update() since it seemed it is matching name for read()/write(), but descriptive name may be better. Any comments for renaming? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11c25d480dccb704f4cafe6d--