I am writing a small program that is a client of some protocol. I wanted this program to have a filesystem database. the main directory would contain one directory for a server that is configured, and the server directory would contain things like server settings in json and other data, this time those are certificates, not sure if certificates would be stored in separate dirs. The question is: if it is possible, even though rare, that multiple instances of this app could access the database, and also this program can run in daemon mode multithreaded, what kinds of locks may be needed for thread and for jvm?

For example, should I use a read/write lock for inter thread synchronization + a shared or exclusive file lock? should I lock the whole database, or only the directory near the set of files I want to change, like the server directory?

  • The short answer is to use a real database, one that supports transactions and that has been rigorously tested. The longer answer starts with a question: what are the consequences of concurrent changes? – kdgregory Nov 3 '16 at 17:39
  • it seems that this case is too simple for a full database. the only thing I am storing in server dirs are certificates, private keys and small number of json files. – Michał Zegan Nov 3 '16 at 17:41
  • what do you mean by the question about consequences of concurrent changes? probably mostly things like the daemon trying to renew a certificate while someone has removed it from database, or rather while someone is trying to remove it – Michał Zegan Nov 3 '16 at 17:45
  • 1
    The minute that you use the words "multiple instances," you have to graduate to a real database. You get all of the capabilities you're talking about here for free. Check out SQLite; every smart phone on the planet uses it. – Robert Harvey Nov 3 '16 at 17:46
  • in this case "multiple instance" just means something like one user runs this thing in a daemon mode, and it starts renewing certificates (that's what the daemon mode would be for), and the second process removes a server. this program is generally a command line application with almost no risk of concurrent usage except concurrent renewal of certificates or accidental use possibly? – Michał Zegan Nov 3 '16 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.