Re: SQLite and callbacks

Stefan Sperling <stsp_at_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.

-- 
Philip