On 01/13/2011 08:25 AM, Stefan Sperling wrote:
> On Wed, Jan 12, 2011 at 09:46:47AM -0500, C. Michael Pilato wrote:
>> Nothing to add to the immediate discussion at this time. Just wanted to
>> note that we have essentially the same problems to deal with in the BDB
>> backend. The solution we've taken there is "don't drive public API
>> callbacks from inside BDB transactions". It's not always the best for
>> performance, but the FS API is such a high profile API for third-party
>> consumers (very unlike the WC API in that respect, I'd imagine) that
>> simplicity of the API "rules" was valued.
>>
>
> This is about callbacks in the libsvn_client(!) and libsvn_wc APIs.
> Those are widely used by third parties so we should really make
> the right decision.
>
> Do we trust third parties to heed restrictions we place on callbacks?
> There is no way can enforce the restrictions.
Really? Our BDB code detects re-entry from within a transaction and errors
out. :-) It does this by keeping a simple boolean state variable that is
set whenever the code enters a BDB transaction, and cleared when the
transaction is committed or aborted. If that variable is set, and some
other code comes along to create a new (nested) transaction, and error is
raised.
Could we do something similar in our SQL logic?
> Or we could decide not to run callbacks while sqlite transactions
> are in progress, and pay some performance overhead. We'd have to
> run multiple queries and provide data to the callback in chunks
> (of, say, directory-sized units). I'm not sure if this would provide
> adequate performance, but I haven't taken any measurements either (yet).
> A recent change of this kind I made to the node walker didn't make
> to make any notable difference.
So, yeah, we really need more information to answer questions of
performance, it seems. In the meantime, we need to answer questions of
correctness, maintainability, and ease-of-use.
> We may need both approaches anyway, if we decide to use the second
> approach in backwards-compat code.
I don't see how we'd ever need both approaches. Can you explain?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-01-13 15:03:54 CET