On 11 Nov 2019, at 5:13pm, Jukka Marin <jukka.ma...@jmp.fi> wrote: > The main process first opens the databases and checks that their > version matches that of the software and if not, the databases are > closed and initialized by running a script. > > After closing the databases, main process forks the children and > all processes (including main process) open the databases and use > their own connections. > > What I was trying to ask was this: If any of the children dies > (a bug in the code), main process will restart the child. At > this point, the main process has the databases open, so the new > child receives the connections as well. What should I do now?
Okay, that gives us enough information to work with. The conservative way to do it is to have the main process close the connection before forking and open it again. Then, of course, the child processes make their own connections. But I don't think that's necessary. A child process can have access to the main process' database connection but ignore it. So I think the main process can fork without closing its connection. Then each child can never use that one but instead make its own. Of course, every one of these connections needs to set a timeout. And every call to the SQLite3 library needs to check its result code and make sure it is getting SQLITE_OK (or, for queries, SQLITE_DONE etc.). > Should the child close the databases before opening them again? > Will this close the databases for the main process as well? As you suspected, closing the connection releases both memory structures and file handles. Anything that tries to use that connection will then fail because it has no idea what it's talking to. What puzzles me is this: you're getting "database malformed" and nothing you've described justifies this. Assuming that this isn't just one old database which is genuinely corrupt, but that you are using a fresh uncorrupt database each time, you seem to have a genuine bug in your code. This happens mostly because something is stomping on the memory assigned to a connection. In your case, this probably means something is stomping on the memory assigned to one of the child processes. So, first write yourself a quick script to use the shell tool to check the database for corruption. Then run that, even while your program is running, and see if you can figure out whether your database really is corrupt or whether your program is getting spurious error messages. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
