On Sun, Aug 29, 2004 at 09:24:59AM -0400, pgsql@mohawksoft.com wrote:
> Think about a website shopping cart. The session and the things in the
> cart don't matter after 10 or 15 minutes. Most of the time, it will just
> be abandoned. The only time it is important is at checkout. At which point
> it is transfered to an ACID compliant system.
Much of the rest of what you said makes sense, but this is a TERRIBLE
example. As a user, I have been burned repeatedly by crappy,
non-persistent shopping carts built by developers who, apparently,
agree with you that, "Oh, it's just a shopping cart, no one cares if
it randomly disappears and the user has to start over from scratch."
Nonsense! Damn it, if put 12 different items in my shopping cart and
then go to lunch, I expect my shopping cart to STILL BE THERE when I
get back! Note that Amazon does this right, so any ecommerce site
doing it WRONG does so at severe peril of losing its customers.
> My session manager on a modern dual PIII can handle 8000 full "get vars,
> set vars" cycles a second.
I don't really see why you need or want to do this in PostgreSQL,
though. Can't you do it in your web or application server? (I
certainly can in AOLserver with its nsv API, for example.)
What's the advantage of instead stuffing these in-memory variables
into PostgreSQL? That it still works correctly and simply even if you
have a farm of 10 separate web servers sitting in front of it? That
could be useful for certain applications, but is there any more to it
than that?
I've occasionally REALLY wanted a small in-memory ACId (no "D" for
Durability) RDBMS for tracking transient data that doesn't need to go
to disk (and one of these days I will experiment with using SQLite for
that), but that's not what you're talking about, right? The shared
variables you're talking about here are just simple scalar values, no
tables, no integrity constraints, no MVCC, none of that, right?
--
Andrew Piskorski <atp@piskorski.com>
http://www.piskorski.com/
