[Seaside] OmniBase for Squeak
Cees de Groot
cg at cdegroot.com
Thu Jan 27 18:06:42 CET 2005
On Thu, 27 Jan 2005 13:09:47 +0100, Avi Bryant <avi.bryant at gmail.com>
> 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 ;)
More information about the Seaside