Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F7CE0F9.7010200@christopherschultz.net>
Date: Wed, 04 Apr 2012 20:02:01 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Who wants my Cassandra session manager for Tomcat?
References: <4F7ABB54.3050906@openjawtech.com> <4F7B2AB1.5070609@pidster.com>
 <4F7B58D5.2050405@christopherschultz.net> <4F7B6936.6090007@openjawtech.com>
 <4F7C2696.5080001@pidster.com>
In-Reply-To: <4F7C2696.5080001@pidster.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig86F21E9FF6CA82DC5995E4CE"

--------------enig86F21E9FF6CA82DC5995E4CE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Pid,

On 4/4/12 6:46 AM, Pid wrote:
> On 03/04/2012 22:18, Morten Jorgensen wrote:
>> Thanks to all for your feedback. I am providing some additional
>> information as requested:
>>> That's interesting.  Can you share some details about how it works?
>> Sure. It is quite simple. Cassandra is effectively a multi-level
>> distributed hash-map, so it lends itself very well do storing session
>> attributes.
>>
>> The session manager maintains two column families (like tables), one t=
o
>> hold session meta-data such as the last access timestamp, etc. and one=

>> column family to hold session attributes. Storing or reading a session=

>> attribute is simply a matter of writing it using the session ID as the=

>> row ID, and the session attribute name as the column name, and the
>> session attribute value as the column value.
>>
>> Session attributes are read and written independently, so the entire w=
eb
>> session does not have to be loaded into memory - only the session
>> attributes that are actually required to service a request are read.
>> This greatly reduces the memory footprint of the web applications that=
 I
>> am developing for my employer.
>=20
> I'd be concerned about how chatty that was.
>=20
> Devil's advocate question: why store data in the session if it's not ne=
eded?

Honestly, I was thinking the same thing today: usually, non-memory-based
data management is usually done in such a way as to be completely
divorced from the HttpSession concept, anyway. One needs to use
HttpSession for things like unique ids being assigned to clients, etc.
but then everything else can be done completely separately from that.

There's no reason that a "CassandraSessionManager" would really need to
exist unless you wanted to have completely seamless Cassandra-based
storage. I would argue that you don't actually want that, since you have
to put so much plumbing code in that you end up being a slave to
HttpSession when what you really want to do is store binary data (since
that's all Cassandra *can* store) and have it bound to some unique
identifier (coincidentally the HttpSession id).

I almost think that a Map implementation (with associated identifier,
which could be session-id-based) with a Cassandra backing-store would be
more useful since you could use it in any container and even entirely
outside a container.

I'm starting to be more like +0 to this idea.

-chris


--------------enig86F21E9FF6CA82DC5995E4CE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk984PsACgkQ9CaO5/Lv0PD8qgCgj8ll36SMlVZzDe90BkTGedgD
mOIAn1YHJfzPIg/hJwtvTbWsFYpjlqS6
=GUfH
-----END PGP SIGNATURE-----

--------------enig86F21E9FF6CA82DC5995E4CE--