I’m developing a project that has multiple programs that share a single, lazy loaded SQLite database file, using Fluent Nhibernate (Auto Mapping) as the data access layer.
The first program I developed (let’s call it Program 1) kept the Session open all the time, and lazy loading worked fine.
This approach failed when I got Program 2 running, and tried to write to the database from Program 2 while Program 1 was running – I got “database locked” exceptions.
I got around this by closing the Session after Program 1 starts up – e.g.
private ISessionFactory _sessionFactory;
private ISession _session;
_sessionFactory = Database.CreateSessionFactory();
_session = _sessionFactory.OpenSession();
_session.BeginTransaction();
// ... read the database here
_session.Close();
Of course, this broke lazy loading in Program 1 when the user selected a different data data set from the user interface – which I had expected.
I thought I would be able to just open the Session again whenever the user selected new data, and then close it again – e.g.
if ( !_session.IsOpen )
_session = _sessionFactory.OpenSession();
if ( !_session.IsConnected )
_session.Reconnect();
_session.BeginTransaction();
// ... read the database here
_session.Close();
But so far, have not been able to get this to work. I get “no session, or session was closed” exception when I try to read the data, even though I’ve just opened a session. (The test for the connection was just an experiment, because the exception trace said something about throwing lazy exceptions when disconnected, but it didn’t help)
What am I doing wrong?
The “database locked” exceptions mysteriously disappeared after I refactored some of the session management code for other reasons. (The main changes were to use Transactions for ALL DB access, and to ensure all Transaction and Session objects were properly Disposed – mainly by enclosing them in “using” blocks).
This link discusses a similar problem that was caused by a missing Dispose. I suspect that may have been my problem, but am not sure.
Another good source of things to try is Database file is inexplicably locked during SQLite commit
In any case, multiple programs are now successfully reading and writing to a single shared SQLite database.