[Seaside] More transaction rambling

[Cees de Groot]

Nevin Pratt wrote:
> 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.
>
Well, the end result is that you do a commit/rollback on the application 
level. In the shopping cart example, the whole thing sits in the 
database and you explicitely need to remove the stuff again when the 
user doesn't make the final step. So at the end of the day, you commit 
the stuff to the database and then do a manual delete as a sort of 
poor-man's rollback.

Making transactions as short-lived as possible is very necessary with 
usual persistence backends, but with multi-versioned concurrency control 
(OmniBase employs that) it is not a big problem.

> 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.
>
That's correct, although with lazy reference fetching you do need the 
transaction to be active for some unspecified time (the user can be 
drilling down, for example, if you are rendering a tree control).

> You created a new account-- a begin db xaction, write data, commit db 
> xaction has happened.  No problem here.
>
In the 'keep db txns as short as possible and do app txns manually' 
model, yes. I'm trying to find a way to merge app txns and db txns, it 
makes much more sense I think and at the very least it's an interesting 
alternative to explore. Seaside is not like anything else I know, so I 
think that warrants a fresh look at things.

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

That's the fifth "Don't do that". Know, I know I'm not a native English 
speaker, but I usually get that (and ignore it) the first time ;-).

Your alternative, one db transaction per web request, is what I 
currently use with .SSP's in VisualWorks. It works, but only so so. 
First, because you need to communicate a lot of objects between 
transactions; second, because you often do a manual rollback if some 
kind of workflow wasn't completed. Furthermore, with Seaside, it'll 
probably work very badly in the case of OmniBase - with every 
transaction, all the persistent objects that hang around in your 
components become invalidated and need to be re-fetched, or you need to 
make sure that everything is accessed through OID proxies.