Re: [jetty-dev] NoSQL Session manager

[Greg Wilkins <gregw@xxxxxxxxxxx>]

On 2 June 2011 05:54, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
> My initial thoughts on this are that it is exceedingly difficult to
> take a broad group of technologies such as those that comprise
> NoSql[1] and come up with a generic implementation or specification
> for something like the session management interface that applied
> generically and equally to all NoSql implementations.

That is a conclusion that I've rapidly come to when looking at the
various technologies.

I think we need to firstly concentrate on what semantic(s) are
applicable to this style of scalable sessions and then see how they
map to the various nosql implementations.  I don't expect that there
will be to much common code between any two nosql implementations -
nor will they provide exactly the same semantics.

<rant>
These annotation-loving nosql freaks keep deluding themselves that
they have persistence layers that work with POJOs! But just look at
the annotations required for one of these
http://code.google.com/p/morphia/.  That's not a plain old java
object!  that's a heavily dependent on a particular frame work object
- just because they are annotations does not make them NOT
dependencies!!!  If they truly supported POJOs, then I should be able
to save the same object in mongoDB, couchDB, orientDB, etc. etc.
without have a bazillion dependencies on all of their frameworks.
Currently with relational databases my domain objects are portable
across many DBs - not so with nosql!!!
</rant>


> To shamelessly pull from wikipedia to illustrate the point:
>
>   NoSQL architectures often provide weak consistency guarantees, such
> as eventual consistency, or transactions restricted to single
>   data items. Some systems, however, provide full ACID guarantees in
> some instances by adding a supplementary
>   middleware layer (e.g., CloudTPS).
>
> It depends on what technology your talking about putting the session
> manager on top that will drive the decisions that need to be made in
> that implementation.  NoSql solutions vary on how they address the CAP
> theorem [2]...and this drives the architecture of the session manager
> as well.  One solution may provide you native ways of dealing with
> consistency and others you might require you to manually manage
> consistency yourself.

I just don't think that state that needs to be consistent belongs in a
HTTPSession.  At best sessions should be caches of data,
authentication or transient state that does not matter greatly if it
is lost.  If you have valuable business data/state that you cannot
afford to lose or have inconsistent - then put it in a DB rather than
a session.

I think the classic example is a shopping cart.  Many e-commerce sites
have a shopping cart held in a session, so if the browser is
restarted, then the shopping cart is emptied and the users have to
start again.  For many stores this is ok, because the time between
filling the cart and checkout is small.   But for other stores that
track their shoppers identities (think amazon), then shopping carts
are too important for a session and are stored in a some kind of DB
(maybe even a nosql DB), so the contents are not transient and they
can try over time to close the sale.




> Pulling from the cassandra (a very popular nosql solution) wiki [3]:
>
>   The CAP theorem states that you have to pick two of Consistency,
> Availability, Partition tolerance: You can't have the three at the
>   same time and get an acceptable latency.
>
>   Cassandra values Availability and Partitioning tolerance (AP).
> Tradeoffs between consistency and latency are tunable in Cassandra.
>   You can get strong consistency with Cassandra (with an increased
> latency). But, you can't get row locking: that is a definite win for
> HBase.
>
>   Note: Hbase values Consistency and Partitioning tolerance (CP)
>
> From what I have seen, you really need to consider the underlying
> technology in play before really designing something like a session
> manager.  Even something as simple as caching in memory or not could
> have an effect on what is happening under the covers, HBase and
> Cassandra can not to be considered 'equivalent' in every way.  Even
> the concept of relying on a master node is not necessarily a safe
> assumption, cassandra really doesn't even had that concept.

I think this is definitely true - we should not try to pave over the
different semantics of the different providers by having our own in
memory cache on top.   The different semantics all have their pros and
cons.  We should work out which ones make sense for HTTP sessions and
provide session managers that expose those semantics.  If we can get
some common code between the implementations then great... but I'm not
holding my breath on that one.


cheers