[Seaside] More transaction rambling

[Cees de Groot]

[OBTW: I just published a new version to the Cincom public repository. A 
new VW source file will follow soon on the Swiki]

Here's an metaphor I use for applications: persistence layer (ie the 
stuff below the application/business model) and user interface layer (ie 
the stuff above...) are the two halves of a pliers (is that correct use 
of the word 'pliers' - I hate these nouns that mix-up singular and 
plural?). You can move the two halves independently, but only by the 
single point where they are linked makes them work.

Similarly, the top and bottom layer need to have a connection point, 
which is the transaction. I find it works best when the business model 
is completely oblivious of persistence and transactions, the application 
layer on top of it will have to deal with it now and then, but most of 
the work needs to be done by the user interface in concert with the 
persistence layer.

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 (to that end, I have extended 
IATransaction with a bit of persistence transaction support; maybe some 
simple transaction manager is in need so you could scope multiple 
transactions).

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. 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 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. 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, 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.

Are there better ideas?