OOFS -- Transactional or Transparent (was Re: Testing the waters.)

[Bill House]

This is an issue that I think bears its own thread. 

The transparent support described by Adam Alpern is very intriguing, but I
wonder how practical it would be for real-world applications (and I say this
without ever actually used such a system, so my wonderment is only natural). In
my experience, performance and application issues would seem to argue against
having the system decide when and where to store objects for me on its own --
sometimes I don't want things saved, and I'm always seeming to need control of
database interactions at the transaction level.

FWIW, in AgentBase, we simply have a native object type -- ObjectRepository.
Once you have one, then you can store anything in it by key.  We also support
transactions:

            (new ObjectRepository: pathString)
		(beginTransaction myOR)
            (setq myOR[someKey] someObject)
            (commitTransaction myOR)

This style is nice in that it makes all sorts of DB-oriented apps very easy to
write. Also, it lends itself to C/S and distributed operation, as the
pathString could be a URL to another server.  

Anyway, how would a transparent OOFS work in the context of such applications?
How would the application programmer control database transactions?

Bill House
--
http://www.dazsi.com
The views expressed are mine alone,
unless you agree with me.