commit 0203e5c57f397865fd5a95b7f91f5f27fd306431
Author: Marius <maerious@gmail.com>
Date: Sat Jan 9 20:39:46 2016 +0100
Update dependencies
commit be5b2b8f62b4644fd9c52a838fe68d98b4eae8e4
Author: Marius <maerious@gmail.com>
Date: Sat Jan 9 19:17:32 2016 +0100
Pull dependencies from vendor/ in /home/marius/workspace/go for Go < 1.5
commit e631bbcc59e4c9e5e928b172b4c6aab6eb71274d
Author: Marius <maerious@gmail.com>
Date: Sat Jan 9 19:15:20 2016 +0100
Vendor dependencies
The reason behind this drastic move was that sometimes a lock needs to
persist across multiple calls to a DataStore. For example, when a PATCH
request is received, following behaviour is wanted:
* Obtain lock (LockUpload)
* Get offset, size etc (GetInfo)
* Write data (WriteChunk)
* Release lock (UnlockUpload)
However, before this change, the lock would be release and then obtained again
after the GetInfo and before the WriteChunk call. This resulted in an
inefficient resource usage and even a possible race condition.
The effects of this change was:
* FileLocker is now directly integrated into FileStore and not sperarated
* LockingStore and the entire package has been removed
* MemoryLocker has been moved into its very own package
The goal is to allow different locking mechanism to be used for different
storages. For example, in-memory for very few uploads, a file locker in
conjunction with the FileStore or an external service, such as ZooKeeper.