Hang at commit time when using sftp or bzr+ssh
John Yates
john.yates at us.ibm.com
Fri Dec 9 16:29:39 UTC 2011
There is a technique I have used and also seen in other caching network
file systems (e.g. NFS v4). The states of the system are identified by a
monotonic counter. Obtaining a lock returns the current value of that
counter. If the counter has not changed since data was last cached
locally then that data can be reused, otherwise a refresh is necessary.
/john
From: Aaron Bentley <aaron at aaronbentley.com>
To: stephen at ck12.org
Cc: bazaar at lists.canonical.com
Date: 12/09/2011 10:28 AM
Subject: Re: Hang at commit time when using sftp or bzr+ssh
Sent by: bazaar-bounces at lists.canonical.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11-12-08 07:23 PM, Stephen Auyeung wrote:
> Another possibility is caching at the higher level. For example,
> caching the master_branch at Branch. I see the code there, but the
> cache is being cleared when unlock is called and that makes the
> cache not very useful. Could it be that only some of the cache need
> to be clear but not all?
Generally the solution is to hold the lock for longer. Is there a
reason that wouldn't work here?
I think we want to avoid the possibility of inconsistency clearing
only part of the cache would introduce.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7iKOkACgkQ0F+nu1YWqI14JACeIAAlH8GwPyNgwKBLnOoeMopD
QwsAn1n2dGabEEXeM2CyyYRFsHqdNP9z
=yRsf
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list