Re: Contrib -- PostgreSQL shared variables

> On Sun, Aug 29, 2004 at 09:24:59AM -0400, pgsql(at)mohawksoft(dot)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.

Your complaint is the timing, not the process. Most web sessions go away,
less than 10% of all shopping carts ever get checked out, period. The
Msession manager has a module that will save expired sessions to a
database and reload them if the session ID ever comes back, if you like.

Listen, I don't want to ramble on about web sessions, that is a different
topic, and I only wanted an example of data that was important to use in
the database, but was not persistent enough or irreplacable enough to
warrent the full ACID overhead. Web sessions are temporary. If you have a
machine that crashes every 9 months which causes all the active sessions
to be lost, this is probably acceptable as long as there is failover. That
is totally unacceptable with regard to a database.

There are classes of undependable or transient and reproducable data in a
system which works in concert with dependable data. It is inefficient to
require the transient data to be managed under the strict guidelines of
the dependable data.

Furthermore, the more independent systems you have within a larger system,
the less reliable the larger system is.

>
>> 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.)

Having managed many projects, I can tell you, point blank, the fewer
things you need to use the better. An extension to an interface you
already use is much better than a different interface.

Also, the data in the shared variables is related to the data in the
database. It belongs close to it.
>
> 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?

Isn't "that could be useful for certain applications" enough of a reason
to add something to contrib?

>
> 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?

Right. The metaphor will be done in almost every non-trivial system. The
developer can either search for some system to do it and figure out some
way to use the data that system in PostgreSQL, or load this contrib
module, and have it at the SQL level.

Honestly, I don't see the problem.