Reply to thread

I have been having a think about our conversation on iterations. In MP, it doesn't really happen much. If you watch live TV, then there is no database activity, and when you watch a movie, there is no database activity for the duration of watching. So, there are long periods of database inactivity.


The opposite is true for Configuration, when it comes to scanning. There are some major bottlenecks, especially when getting and storing actors for movies and generating actorlinkmovie records. If we were using SQL Server, this wouldn't matter - we would simply do things in the most efficient way and allow the database engine to handle the asynchronous processing. But with SQLite things are different. We have to allow space for MP user clients to do their occasional database activity. This is something I have been aware of and have been thinking about how best to handle things. My thought is to warn the user, about to do scan, that what they are doing may interfere with other household users and give them the choice whether to take the fastest option (which will lock other users out) or the less efficient option or do the scan when no-one else is using MP. Obviously, the wording will be important.


I have a methodology for handling batch processing that goes something like this (in pseudo code):


if using batch mode

{

do stuff

}

else

{

using ()

{

do stuff

}

}


The calling code either sets batch mode on and does an explicit connect, disconnecting at the end of the batch processing and setting batch mode off, or does the call with batch mode off.


This is the normal way I write the database accessing code. I didn't do it in MP because it is interactive for most of the time. But I could put this conditioning in when it is beneficial, like during a scan.


It's always going to be a trade-off between performance and co-operation, getting the users to understand they have to work together, with SQLite :)


I'll have a good look at this. It's something I've dealt with many times before; my version of MPSync, for example. It was to get away from having to synchronize that I embarked on this project in the first place because synchronizing data when it's locked most of the time is problematic, to say the least.


Top Bottom