cmpilato@collab.net wrote:
>So, I'm remember how we print error messages, it looks like the
>deadlock happens first, and *then* the "already exists" is tacked onto
>it.
>
> err = svn_fs__bdb_get_node_revision (NULL, fs, new_id, trail);
> if ((! err) || (err->apr_err != SVN_ERR_FS_ID_NOT_FOUND))
> {
> svn_string_t *id_str = svn_fs_unparse_id (id, trail->pool);
> svn_string_t *new_id_str = svn_fs_unparse_id (new_id, trail->pool);
> return svn_error_createf
> (SVN_ERR_FS_ALREADY_EXISTS, err,
> "successor id `%s' (for `%s') already exists in filesystem '%s'",
> new_id_str->data, id_str->data, fs->path);
> }
>
>Ah. So, our error message isn't really all that helpful, since any
>error except "not found" (include "deadlock error") will make it
>appear that there is, to use TuttSpeak :-), a NodeRev PK conflict. I
>remain confident that our filesystem code isn't generating clashing
>node-rev-ids.
>
Right, I was pretty certain of that myself.
>Still, the deadlock concerns me.
>
>
Yes. The granularity of our transactions is far, far too large, and we
have absolutely no control over locking order. I'm 99% certain that's
where the deadlock comes from -- we simply don't access the various BDB
tables in a well-known order, and we keep stuff locked longer than
necessary.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 20 08:27:55 2003