2007/6/28, Ian Eslick <[EMAIL PROTECTED]>:
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
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
