[elephant-devel] DB Transactions and UI

[Pierre THIERRY]

Scribit Mariano Montone dies 27/06/2007 hora 13:12:
> I've been developing web applications so far, so I'll be describing a
> web UI.

I've been making web apps too, mostly. I don't think it's web specific,
but it's probably worse in web UIs, because they have a much worse
latency than GUIs running locally.

> There are cases in which a user wants to perform several operations in
> a transactional way.

Do you have examples? The only cases where my own apps needed several
pages for an operation were creation operation, IIRC. On the other hand,
there is at least one famous example, namely most online shops checkout
operation. On Amazon, ISTR you go through 3 or 4 pages to checkout. I
never tried to update my cart while doing that. I wonder how it behaves.

> The problem is that long transactions are not supported by today
> databases. When I say long transactions I mean the ones that have a
> lifetime related to the user interaction with the application.

The good thing may be that the semantics and some practical implication
are msotly the same. The interactions of long transactions may be
radically different than of extremely short ones, though.

They may fail more, and be slower to restart. It would be fairly
important to identify what transactions can be silently restarted and
which need user input again. When this is needed, it will take a huge
time for the new transaction to be committed, compared to when it is
automatically restarted.

> The consecuence is that the user may have performed operations based
> on some knowleadge that will not hold if the transaction gets
> restarted silently.

That would be a bug. Transactions that are restarted are code, and this
code makes decisions based on data it sees. In STM, for example, the
side-effects of a restarted transaction could be different from those of
its first run.

> The application is not aware of that and the user is not warned of
> that (the new query results are never displayed again to the user).

The application must be aware of what data was read to build the UI from
which the user made decisions.

> The algorithm would be similar to the one used for STM [1]. It doesn't
> lock records and deadlock cannot occur.

There is a huge difference with STM, in that there is a huge latency in
our case. This opens up a vulnerability on denial of service. If an
hostile agent manages to modify some data often enough, it can prevent
the user from committing his own modifications.

This means that locking should be made available to the user, so that it
can protect himself from that (of course, that means he can DoS others,
and you have to deal with that also...).

>      1) Does what I am saying make any sense? :)

Definitely. That could be a good step towards making some applications
more robust.

>      2) How do you attack these problems in your applications?

By ignoring them. ;-)

Now that I think of it, I'm pretty sure many of my applications are
vulnerable when multiple users make overlapping modifications. This
means some modifications will be silently overwritten, sometimes making
the whole data set inconsistent.

That's an interesting issue, BTW.

Curiously,
Pierre
-- 
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20070628/452efbfd/attachment.sig>