On 16.02.2011 11:52, Philip Martin wrote:
> Stefan Sperling <s...@elego.de> writes:
>
>> [[[
>> Improve performance of svn proplist in a similar way as was done in r1039808.
>> But, this time, avoid problems with callbacks invoked during sqlite
>> transactions by storing results in a temporary table and invoking
>> callbacks during a query on the temporary table.
>> +read_props_recursive(svn_wc__db_t *db,
>> + const char *local_abspath,
>> + svn_boolean_t files_only,
>> + svn_boolean_t immediates_only,
>> + svn_wc__proplist_receiver_t receiver_func,
>> + void *receiver_baton,
>> + svn_cancel_func_t cancel_func,
>> + void *cancel_baton,
>> + apr_pool_t *scratch_pool)
>> {
>> svn_wc__db_wcroot_t *wcroot;
>> - const char *local_relpath;
>> - const char *prev_child_relpath;
>> svn_sqlite__stmt_t *stmt;
>> + cache_props_baton_t baton;
>> svn_boolean_t have_row;
>> - apr_hash_t *props_per_child;
>> - apr_hash_t *files;
>> - apr_hash_t *not_present;
>> - apr_hash_index_t *hi;
>> + int row_number;
>> apr_pool_t *iterpool;
>>
>> SVN_ERR_ASSERT(svn_dirent_is_absolute(local_abspath));
>> SVN_ERR_ASSERT(receiver_func);
>>
>> - SVN_ERR(svn_wc__db_wcroot_parse_local_abspath(&wcroot, &local_relpath, db,
>> - local_abspath,
>> - svn_sqlite__mode_readwrite,
>> - scratch_pool, scratch_pool));
>> + SVN_ERR(svn_wc__db_wcroot_parse_local_abspath(&wcroot,
>> &baton.local_relpath,
>> + db, local_abspath,
>> + svn_sqlite__mode_readwrite,
>> + scratch_pool,
>> scratch_pool));
>> VERIFY_USABLE_WCROOT(wcroot);
>>
>> - props_per_child = apr_hash_make(scratch_pool);
>> - not_present = apr_hash_make(scratch_pool);
>> - if (files_only)
>> - files = apr_hash_make(scratch_pool);
>> + SVN_ERR(svn_sqlite__exec_statements(wcroot->sdb,
>> + STMT_CLEAR_NODE_PROPS_CACHE));
>> +
> As far as I can see there is only one cache, and so there has to be some
> sort of serialisation to prevent multiple callers interfering with each
> other. For a write operation that is simple, the working copy locks
> will only allow one operation at a time. proplist doesn't take a lock,
> do we need to serialise it somehow? Should we be using views with
> per-transaction names? If we did how would we clear old views for
> clients that exited unexpectedly?
>
> I'm thinking of using something like this for recursive revert. It's
> easy to delete WORKING/ACTUAL rows in a single query, but hard to
> notify, particularly as the rows don't exist after the revert. Since
> revert is a write operation the working copy lock should serialise
> things
The single cache is a temporary table, which has distinct per-connection
instances. If some other thread is using the same connection at the same
time, all bets are off anyway, because transactions are per-connection,
too. The cache is filled within a single sqlite transaction, so I assume
that the cached state is consistent. In fact, it's better than before,
when a recursive proplist would work its way throuth any number of
transactions, making the consistency of the result doubtful at best.
-- Brane
