Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70137
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <528541CD.1040706@sugarcrm.com>
References: <CAGa2bXb7hR=jkHnxrBDXnSZkN7B6cDVPj_Nve2=tWS4_AmmOKg@mail.gmail.com>
 <CADajX4CJ061_1b__TAT_6vjNJ9Z+_N6bqN2CA63d+8gvxf4BXQ@mail.gmail.com>
 <5285390D.6000106@sugarcrm.com> <CAGa2bXZ99mW003=wZ021gNUxVJ3z6KxUUYMUYJh3QdiDEwQFRA@mail.gmail.com>
 <52853E69.5040104@sugarcrm.com> <CAGa2bXZjF_WVynzRyMRaF6XYC2DYYb36fO+nFp9cJ3MaaHbaZA@mail.gmail.com>
 <528541CD.1040706@sugarcrm.com>
Date: Fri, 15 Nov 2013 06:47:45 +0900
Message-ID: <CAGa2bXYbOFdD-yusRE9KeDb6QdeYibMW8kABruV2k5xkH=cn2Q@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Adam Harvey <aharvey@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0117720f8f7d2204eb2a0aee
Subject: Re: [PHP-DEV] Session cache, lock and write
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0117720f8f7d2204eb2a0aee
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Fri, Nov 15, 2013 at 6:34 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > 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.


I agree your concern and I knew well what could be wrong since
I forgot to set "serializable" transaction option when I made session_pgsql
save handler.

However, I think this feature would be nice as optional feature with
BIG caution.

I hope many users are used to "unlocked" session data already thanks
to memcached/memcache/mongodb session save handlers.

I'll make this a voting option.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0117720f8f7d2204eb2a0aee--