[elephant-devel] DB Transactions and UI

[Mariano Montone]

2007/6/28, Ian Eslick <eslick at csail.mit.edu>:
>
> Just a few short comments:
>
> 1) I think that DBs are designed for certain kinds of short-running
> transactions, but over time have been co-opted into supporting longer
> and more complex ones.


Which DBs are you talking about in particular? I'm interested in open-source
ones with this kind of transaction support.

2) User interaction takes place in a completely different domain and
> I think that the constraints of that domain should not be conflated
> with the low-level DB semantics.


That is true. But I also think that UI semantics should not be confalted
with DB semantics. In practice, I usually end up sacrifying some kinds of UI
interactions because of how the DB world behaves. I don't like the
separation there is from the application and the DB. I don't like the DB
being such a black box. I wish they could interact better.

3) As for user interactions like checkout; I think you probably want
> to implement your own dependency tracking, for example a multi-stage
> process for buying tickets.  Here we use two levels of transactions
> and a DB field to perform application-level locking.
>
> GUI:
> User searches for and selects some tickets.  Those tickets are added
> to a user record that can be non-durable (simple, in-memory object)
> or durable (a database record updated after every page refresh)
> depending on the criticality of the application.
>
> DB:
> Short transaction moves these from an available state to a pending
> state with a timestamp and a reference to the user record so it can
> be automatically reclaimed if the user fails to complete the order in
> a certain timeframe.
>
> GUI:
> User goes through several steps, updating the user record at each
> step and then committing the order.
>
> DB:
> Transaction: change the ticket state to pending payment, user record
> updated to record the order info
>
> Network:
> Billing confirmation
>
> DB:
> Transaction: update ticket to purchased, user record to complete
> purchase, drop user object
>
> GUI:
> Send final confirmation to user.
>
>
> Here we have a user-visible transaction implemented in a set of DB
> transactions.  Each DB transaction is short lived, even if the user
> transaction lasts minutes.


Yes, but a set of DB transactions is not semantically equivalent to just
one. It may work in practice (that's the way we all do it), but it looks
more like a work around than a natural solution.

What is the default policy used for SQL-based web frameworks in PHP,
> Ruby-on-Rails, Java, etc?  This can't be the first time this question
> has been asked and answered.


I can tell you from my experience  developing in PHP and MySQL. These
problems are addressed simulating a transaction with a set of little ones,
sacrifying UI design and usability and ignoring some consistency issues.

I'm not just theorizing about these issues. We have developed a web
framework and would like to generate some interfaces automatically.
Unfortunately, this issues are pulling us back in some cases.

Mariano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20070628/61fc0a6d/attachment.html>