<br><br><div><span class="gmail_quote">2007/6/28, Ian Eslick <<a href="mailto:eslick@csail.mit.edu">eslick@csail.mit.edu</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just a few short comments:<br><br>1) I think that DBs are designed for certain kinds of short-running<br>transactions, but over time have been co-opted into supporting longer<br>and more complex ones.</blockquote><div><br>
Which DBs are you talking about in particular? I'm interested in open-source ones with this kind of transaction support.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) User interaction takes place in a completely different domain and<br>I think that the constraints of that domain should not be conflated<br>with the low-level DB semantics.</blockquote><div><br>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. 
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3) As for user interactions like checkout; I think you probably want<br>to implement your own dependency tracking, for example a multi-stage
<br>process for buying tickets.  Here we use two levels of transactions<br>and a DB field to perform application-level locking.<br><br>GUI:<br>User searches for and selects some tickets.  Those tickets are added<br>to a user record that can be non-durable (simple, in-memory object)
<br>or durable (a database record updated after every page refresh)<br>depending on the criticality of the application.<br><br>DB:<br>Short transaction moves these from an available state to a pending<br>state with a timestamp and a reference to the user record so it can
<br>be automatically reclaimed if the user fails to complete the order in<br>a certain timeframe.<br><br>GUI:<br>User goes through several steps, updating the user record at each<br>step and then committing the order.<br>
<br>DB:<br>Transaction: change the ticket state to pending payment, user record<br>updated to record the order info<br><br>Network:<br>Billing confirmation<br><br>DB:<br>Transaction: update ticket to purchased, user record to complete
<br>purchase, drop user object<br><br>GUI:<br>Send final confirmation to user.<br><br><br>Here we have a user-visible transaction implemented in a set of DB<br>transactions.  Each DB transaction is short lived, even if the user
<br>transaction lasts minutes.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">What is the default policy used for SQL-based web frameworks in PHP,<br>Ruby-on-Rails, Java, etc?  This can't be the first time this question
<br>has been asked and answered.</blockquote><div><br>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.
<br><br>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.<br></div><br>
</div>Mariano<br>