Closed zserge closed 9 years ago
Cheers!
To your first point, diskv deliberately punts on anything more sophisticated that simple read-thru caching, including things like transactional synchronization. So for the behavior you want, I'd suggest writing a TransactionalDiskv wrapper, which would synchronize at whatever granularity you wanted (could be global, could be per-key) and serialize your compare-and-set operations that way. Make sense? If you made it reasonably generic, maybe it would make a good subpackage (github.com/peterbourgon/diskv/transactional
or something) — if you felt up for a PR :)
Second, yes, it's an oversight that the mutex is public. I'll privatize it.
Thanks for the feedback! Let me know...
Diskv looks like a nice storage with good performance and simple API, thanks for writing it!
I'm looking for a simple+fast way to update a value in the store. Say, I want to read my object from the store, modify some of its properties and write it back. I want this whole sequence to be goroutine-safe so only one thread could modify the object at a time. And ideally I'd prefer not to use a single global lock. What would you recommend?
As for the global lock - I may use multiple diskv instances (like a pool) and for each key find a suitable instance first, then lock/unlock it. I see that Diskv structure already has a mutex (which is public) and that mutex is used internally to synchronize reads and writes. Since Go mutex is not reentrant - I think it's somewhat unsafe to expose this mutex. Am I right, that despite of being public - I should not use that mutex to lock/unlock Diskv instance?