[Seaside] More transaction rambling

[Nevin Pratt]

Cees de Groot wrote:


> In Seaside, the user interface already has a transaction concept. At the 
> moment, I'm trying to make sure that Omnibase transactions are scoped 
> exactly the same as Seaside transactions 


I don't believe I would do that.  I don't consider an "http" transaction 
to be at all related to the database transactions.

Consider a classic mainframe app (not a web app) where you have 
terminals hooked to a central computer.  In such a configuration, the OS 
needs to associate a given terminal line with a given OS process. 
That's basically what an http transaction for a web app does-- associate 
a given "terminal" line (speaking loosely here) with a given application 
process.  There's not much relationship between that and database 
transactions.  Don't try to merge the two concepts, and life is simpler.

I would adopt the rule of never having an open database transaction.  I 
wouldn't let db transactions spawn across web pages anymore than I would 
let open database transactions spawn across screens of a classic 
client/server app, or even a terminal-based app.  Instead, the db 
transaction is an atomic part of the submit action for a given web page 
(or the "Save" button of a client/server app, or the "Go" key for a 
terminal-based app, etc).  As a result of invoking the save action, you 
(1) begin a db xaction, (2) update the db, and (3) commit the db 
xaction.  You do this all as one atomic action, all without user 
interaction between the steps, and all as a part of the submit action of 
the page.  Thus, no db xaction lasts longer than a few milliseconds.

I do this with classic client/server apps as well-- not just web apps. 
I can't imagine letting a transaction spawn over multiple screens 
regardless of the type of app it is, web app or otherwise.


> 
> Here is an interesting example: you go to the main menu, it is 
> dynamically generated from the database, so resides in a (read-only) 
> transaction.


Why?  From a db transaction perspective, there is no transaction.  You 
might have read the menu from the database, and installed it 
dynamically, but after that, there is no need for any ongoing 
transaction, read-only or otherwise.

> You select 'shop', and enter a new transaction for the 
> whole shopping bit (Seasides IASession>>protect: stuff). When you're 
> done, you proceed to checkout. As you are a new user, you create a new 
> account - a mail confirmation is sent to you.


You created a new account-- a begin db xaction, write data, commit db 
xaction has happened.  No problem here.

> You are running 
> Windows'9x, so that's the time your computer freezes.
> 
> The user expectation here is that you will not have an order, but you 
> will have an account.


If you don't maintain a 1-to-1 between Seaside xactions and db xactions, 
this is exactly what you will have at this point.  You only get into 
trouble when you try to merge the two types of "transactions".  Don't do 
that.

> Certainly because when you finished rebooting, 
> your mail folder contains a message that your account was created. Of 
> course, the order itself never is created - when the session times out, 
> the transaction is garbage collected.
> 
> So, you need two transactions


You only have trouble because of trying to merge the two types of 
"transactions".  Don't do that, and you don't need two concurrent 
transactions.

> but nested dependent transactions is 
> something a lot of databases don't support, and nested independent 
> transactions won't work: if you create the user in an inner transaction 
> which is nested independent, the outer transaction will not know about 
> the new user, it is not in scope. So you would need to have everything 
> in a single transaction, but then you don't match user expectations.
> 
> One solution I'm thinking about is indeed a transaction manager. The 
> email sending becomes part of the managed transaction, and only on 
> commit of the whole single transaction, a mail is sent; if you roll back 
> the transaction, a mail is sent too telling that the user account wasn't 
> created. Or maybe, you have the user account creation separately so that 
> even on rollback, a fresh transaction just creates the account.


That's a lot of added complexity, just because of trying to merge two 
different types of "transactions", which I don't consider to be related 
anyway.  Don't do that, and you don't need this extra complexity.


> Are there better ideas?


Do I sound like a broken-record yet?  :-)

Nevin