[Seaside] OmniBase for Squeak

[Cees de Groot]

On Thu, 27 Jan 2005 13:09:47 +0100, Avi Bryant <avi.bryant at gmail.com>  
wrote:
> A project at a client site has been using it in production for about a
> year now.

And we've hammered away at OmniBase (ok, in VW) for 3 years now. It's fast  
and stable enough.

> The biggest gotcha is hanging on to references
> across transactions: we use one transaction per request/response
> cycle, and OmniBase represents the same object by a different instance
> in each transaction, which means that if you want to refer to the same
> obejct in a callback that you had when generating a response, you need
> to introduce an extra level of indirection that resolves to the
> version appropriate to the current transaction.

Lest people think that OmniBase is doing something funny here, actually it  
isn't. OmniBase supports MVCC (with Oracle and Postgres the only DB's I  
know of that support it), which means that readers never wait for writers,  
and vice versa. It's logical to have instances-per-transaction in this  
case, and if you, as is customary, map a database transaction onto a  
request/response cycle, you get yourself into trouble if you want to move  
arbitrary persistent objects between transactions.

I experimented with mapping the db transactions onto business transactions  
(instead of onto web transactions), but not inside Seaside. I think it  
should be possible to do that and have something relatively clean, but of  
course you get the other issue of long-lived locks hanging around (client  
starts something and then goes away for coffee); MVCC makes this usually  
not a problem, with the exception that if A locks an object for writing  
and goes out for lunch, B can still read the previous copy but cannot  
write it. You can't have your cake and eat it too, it seems.

For The InternetOne (not seaside, but something that looks similar in the  
meantime ;)) we moved most of this stuff away in abstraction layers. In  
fact, we have an abstraction layer that does a lot of work based on  
metadata declarations (object A has attributes X, Y, Z; attribute X is of  
type Foo; etcetera). Most of the database I/O has become relatively  
transparent in that framework and it sports full timetravel as well  
(transparently, mostly). But that of course is a thick layer to paste onto  
something relatively elegant as OmniBase and Seaside below. Did I say that  
you can't have your cake and eat it too?

There's a paper by, I think, Jim Waldo somewhere on the perils of  
transparent networking. Most of his arguments map to transparent  
persistence as well. I used to think this was a holy grail, but nowadays,  
I'm more inclined towards good old manual labour ;)