Message from discussion Don't make cookie-stored sessions a default

Received: by 10.140.201.1 with SMTP id y1mr2655977rvf.1195599421411;
        Tue, 20 Nov 2007 14:57:01 -0800 (PST)
Return-Path: <j...@hasmanythrough.com>
Received: from randymail-a3.g.dreamhost.com (sd-green-bigip-207.dreamhost.com [208.97.132.207])
        by mx.google.com with ESMTP id k36si10610179waf.2007.11.20.14.57.01;
        Tue, 20 Nov 2007 14:57:01 -0800 (PST)
Received-SPF: neutral (google.com: 208.97.132.207 is neither permitted nor denied by best guess record for domain of j...@hasmanythrough.com) client-ip=208.97.132.207;
Authentication-Results: mx.google.com; spf=neutral (google.com: 208.97.132.207 is neither permitted nor denied by best guess record for domain of j...@hasmanythrough.com) smtp.mail=j...@hasmanythrough.com
Received: from [172.17.1.117] (204-16-153-246-static.ipnetworksinc.net [204.16.153.246])
	by randymail-a3.g.dreamhost.com (Postfix) with ESMTP id 50785185C17
	for <rubyonrails-core@googlegroups.com>; Tue, 20 Nov 2007 14:57:00 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <ef46c93e0711201439q214e8ebeqe32460eac7e11317@mail.gmail.com>
References: <78c95ac67074d935a4ca36bc5fa31298@ruby-forum.com> <ef46c93e0711201439q214e8ebeqe32460eac7e11317@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <591F4673-A630-4EF3-91C6-072C59D08236@hasmanythrough.com>
Content-Transfer-Encoding: 7bit
From: Josh Susser <j...@hasmanythrough.com>
Subject: Re: [Rails-core] Re: Don't make cookie-stored sessions a default
Date: Tue, 20 Nov 2007 14:56:59 -0800
To: rubyonrails-core@googlegroups.com
X-Mailer: Apple Mail (2.752.3)


On Nov 20, 2007, at 2:39 PM, Michael Koziarski wrote:
> It's worth considering the 1.2 behaviour. The default session store is
> completely unusable when running on multiple application servers and
> even on a single application server problems with performance and
> deadlocks are frequently reported.
>
> So almost every prodution rails application has already switched to
> active_record_store or some other alternative and their apps will
> continue to use this alternative store. New applications will have the
> opportunity to make that one line change if they like. If someone
> wants to prepare a document describing the relative risks and merits
> of the different session stores, we can make sure it's referenced
> prominently in the relevant places.

The unworkability of the default pstore sessions forces developers to  
move to a workable solution using ActiveRecordStore, MemCacheStore,  
etc.  Cookie session store doesn't break, so it doesn't force a move  
to another system.  I wonder if documenting risks will be enough to  
get people to change when they should.

--
Josh Susser
http://blog.hasmanythrough.com