OOFS

[Kelly Murray]

> People just want to write apps, they don't want to have to deal with
> database issues all over the place.

Right, which makes implicit page-level locking better, since apps
don't *have* to care at all about locking.
They *do* have to care about transaction restarts, which means
you can't cache persistent data in transient memory, since the
transient memory doesn't get "undone" after a restat.
If the persistent access is fast enough, this caching won't be needed.

> One or two tweaks to state lock intentions people will accept.

I'm not sure about that, but let's assume they will.
So you're saying not per-object locks, but just one or two?
This can easily end up serializing everything,
because programs must get these few locks "up front",
so they all end up waiting in line, and don't do anything useful until
it's their turn.  

This doesn't sound like row-level locking, but the same kind of table-level
locking that you were saying the RDB vendors have stopped using.

Fine-grained object-level locking is clearly optimal,
but I don't know any way it can be implemented very efficiently.

> Sure, but who wants locks on a single process system?

If there are explicit locking/unlocking calls in the sources, 
then the lock-code must be run if there is nobody else also running.

Or are you saying that single process execution is not important
enough to optimize for?  

-kelly