On Wed, May 14, 2008 at 3:40 PM, Jay A. Kreibich <[EMAIL PROTECTED]> wrote:
> >> >> WORKAROUNDS: >> >> Or, brute force: Copy the file locally, do your stuff, copy it back. >> > Looks like the brute force solution is the only answer here. (Translated automatically from the Spanish original) ... There is a special type that we could consider "implementation", called "Opportunistic cache". It is linked to the problems of locking files in multi-user environments in which different applications can access the same data. In these cases, operating systems have mechanisms so that a user (application program) obtain the blocking of an entire file or part thereof. The theory is that while maintaining the lock, no one else can modify the file (perhaps read), and that once completed modifications, the user unlocks the file so that others can use it. However, under certain network applications, and in order to improve performance, using a mixed system called "Opportunistic locking", in which the user communicates to the system that will use this modality. To do this, you get a copy of the entire file, which stores a local opportunistic cache. Thus, the transactions are faster than if you have to be conducted through the network requests for different pieces, along with the relevant requests of lock/unlock. Finally, when the user has completed transactions with the file, the server returns an updated copy. The problem arises when, in the interim, another user requests to use the same file. The incidence is particularly prevalent when the file is too big to handle. Why then, even for a minor change, the first user may be delayed enough to return the amended version to the server. The solution adopted to avoid excessive delays, is that, upon receipt of the request of the second user, the system sends an order to the first stopping oplock and return the file as it stands at this time so that the second user can use it. Although not without its problems, especially in unreliable networks unreliable, the system allows yield increases of around 30%. Not so much by the locking system used, for the fact that data have been previously cached by the user. HTH Adolfo _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
