First, thanks for taking time to write some documentation.

Jesus Cea  wrote:
> Transactions under DSS are Isolated. If you don't do any dirty
> trick, DSS garantee a "degree 3 isolation". That is, you only
> see committed data and reads are repeatable.
>
> You shouldn't do it, but if you manually request
> cache shrink, DSS would only garantee "degree 2 isolation".
> That is, you could get different data in two reads to the
> same object.

It was my intention to make it safe to shrink the cache within a
transaction.  The set of "seen" OIDs is stored separately (see the
loaded_oids attribute of the Cache object).  Reviewing the code
right now leads me to believe that your statement is correct and
that the code is buggy.  Calling shrink() can remove OIDs from
loaded_oids within a transaction.

> If your commit success, your cache is untouched. <- VERIFY THIS

I believe that's correct.  If you had anything invalid in the cache
then a ConflictError would be raised.

> TODO: to document the reason because "degree 2" and "degree 3" isolations.

We should fix the bug, IMO.

> TODO: doing an "abort" before beginning a transaction.

We thought about having a sync() method but decided that sync()
really was the same as calling abort.

  Neil