Vici coolstorage additional threads

Question

I have a relatively small project on monotouch for iPhone & Android with plans to add WP7. I use vici coolstorage as an ORM on SQLite, and it works fine for me, but there is one issue. It creates additional threads per thread using db. I already hit the limit of threads as the application is massively parallel, so I want to change it. I found out that thread creation is performed in CSConfig.cs where for each call to GetDB from different thread a new thread is created:

    internal static CSDataProvider GetDB(string strContext)
    {
        if (_threadData == null)
            _threadData = new ThreadData();

        return _threadData.GetDB(strContext);
    }

The _threadData is marked [ThreadStatic]. I suppose this GetDB is called each time I use the ORM (I set default DB in CSConfig to my DB). The thread is created inside ThreadData constructor. And the thread executes this function:

        private void CleanupBehind()
        {
            _callingThread.Join();

            foreach (CSDataProvider db in _threadDbMap.Values)
                db.Dispose();
        }

So, essentially it waits for the caller to terminate and then disposes database connection.

The question is, how can I override this behavior and either let GC dispose the database connections or call the Dispose() myself before the calling thread terminates (I control all the threads using DB, so I can do it). I know it is not good not to let the ORM handle disconnection when the thread ends, but I can not work with one additional thread per worker thread.

Answer 1

Okay I know it's bad to answer own questions, but still. Maybe it can help someone. I have done a workaround, which is to add a function for the cleanup to the CSConfig. I have removed the thread creation altogether and call the cleanup before any thread using the database terminates. Thus I have no extra threads.

It has caused a problem: I use a forced threads termination on some occasions, mostly when threads are inside net operations. So, from time to time I have to iterate through all database connections and remove any that belong to dead threads.

But after all I've got almost twice less threads.