It has been a while since I looked at this. I have had this running for almost 18 months.
When I first set up the calibre server, I had the problem that it never reloaded a changed database. I (and monit) did see the timestamp change, so the file was indeed being modified. I surmised without any proof that dropbox was using delete/add instead of open/rewrite, which could account for the problem by leaving calibre with a disconnected inode.
As for atomicity, I have no evidence that dropbox is deleting *before* adding. If I were them I would do the job with a temp file and by messing with hard links. The dropbox linux client I have is in python (all .so files) and includes librsync.so, so I suspect that it is using rsync-like semantics.
Of course, the above doesn't deal the problem of why calibre never reacted to the mtime change. I just looked at the content server code and I can't find where it reopens the db. The db is initiallly opened in server.main.py on line 121. I see places that reread the db but nowhere that actually reopens the db, which it clearly must do if the sync client does its job with links instead of overwriting the file itself. Am I being blind?
The problems using dropbox and calibre together come from dropbox being a 2-way mirroring system. By copying the db there is no possibility of the database's modtime changing, which might happen because calibre opens the db R/W. As a result, dropbox will never want to copy it up to the cloud, eliminating the possibility of conflicts. Using a one-way sync system eliminates this concern.
In the end, using monit, copying the db, and telling calibre to use that copy does three things for me. The first is that it works.
The second is that it addresses a bit of my paranoia by ensuring that the server is cleanly started using a db that won't be tampered with. The third is another bit of paranoia: that there is something watching in case the server crashes for some reason. I use the same technique for other daemons such as sendmail (and its milters) and dropbox.