4 ms·
I'm looking at a project right now where I'm planning to use SQLite as a high-level solution to file locking (i.e. create a record in the DB to "lock" a file, d
by theseoafs 10y ago
I'm looking at a project right now where I'm planning to use SQLite as a high-level solution to file locking (i.e. create a record in the DB to "lock" a file, delete it when you're done, and don't create a record if a record for that file is already in the DB). Sound like an appropriate use of SQLite? Is there a better, more direct solution? (I understand there are platform-specific utilities but I would want something portable.)
- chj 10y agoThis is what people say you bring whole jungle just because you want the banana.
- theseoafs 10y agoFor the record, the application already has SQLite, I just figured I would use it while it's there.
- AtheistOfFail 10y agoThe main argument against is that a SQLite lock won't stop other processes from messing with the file, instead use a system-based lock.
- mappu 10y agoYou'll need a solution to handle stale locks if the process dies without removing the record.
- tracker1 10y agoMost higher level languages have a flock or equivalent library that is cross platform (win/linux/mac). If you need exclusive locks, I haven't seen an interface for accessing files in languages above C that don't have exclusive lock already.
- mirekrusin 10y agoIt's not a good idea because different processes shouldn't write to the same sqlite database. Unless you design it as a service, where one process is using sqlite to store its locking data and you use it from other processes by communicating with this service - then it's ok.