[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-bdb performance



You wrote:
> 
> As I understand it, reading outside the transaction is still safe (locked),
> it just has no repeatability guarantees. That is acceptable in the case of
> an add where we're only looking for the existence of the parent and checking
> some ACLs. If the parent is changed after we fetch it, that is irrelevant
> for the span of the current add transaction. Of course, if the current
> transaction aborts and we retry from the beginning, re-fetching the parent,
> we may get a different one with different properties. That's still OK
> because we will never leave things in an uncertain state.
> 
Well, maybe I wasn't clear enough. by changing I also mean deletion. Changing
only is of course no problem, but if you delete the parent after you've
checked it exists and before you put all kind of fancy children info into
the parent, the latter fails. Null txn reading without a cursor releases
the page locks immediately. It never was about repeatability, but about
making sure the parent stays around while the add lasts.

> Things might be more problematic for something like modrdn, I'll have to
> look at that later. This is another point in back-hdb's favor, the parent is
> completely independent of changes made to child nodes. (Although I have to
Can you elaborate a bit more on your scheme? Because there might be some
nasty problems but I can't speculate unless I have some more details..

> 
> This is why I mentioned better deadlock avoidance as an ultimate goal;
> whether or not the increased granularity helps your retry time, it's a lot
> of effort for very little gain. And the gain from deadlock avoidance far
> overshadows it.

To avoid is always better than to cure. I only use it at one point.
It is also not very practical to use it more than once during an operation
like add, because you either have to abort/commit the child or start a
new child. The first leads to violation of your degree 3 isolation and the
second adds only a lot of overhead.

-- 
Marijn@bitpit.net
---
If there's one thing I can't stand, it's intolerance.