Normal
Not fully related, but just in case anybody else thinks about this:I was doing similar but with similar approach in the past:Using sync tool, I did a one way synchronization from the server share to a local folder like e.g. c:\data, including the catalog file and the cover art.MyFilms config then used the local copy - whatever was changed, never touched the server file.Big advantage:The local copy was on local SSD drive, thus it was stunning fast for both opening/reading the catalog and the artwork (which takes some time, when you do that via network / NAS). Yes, fully correct - reason see below. It is all about finding a good compromise between safety, when accessing and/or changing data and locking. We don't want to lock too much, as otherwise GUI might have to wait too long in certain situations to finish certain methods - but we must makle sure, data is consistant.So normal "read" access should NOT be exclusive and should NOT prevent other instances to perform actions (think about e.g. trakt updating in the background).All this is even more complicated, if you access the DB file from multiple PCs - as you're not only in different threads, but not even in different tasks anymore. We had problems in the past, that the normal stream parameters did not work well for this - and if you leave windows (using NAS with SAMBA etc.), we can't be sure anymore, that the on board stuff works - that's why we use a locking file that is independant of the filesystem access API features (network access is different than local filesystem access).However, quite possible, that this could be done in a better way - much of the code evolved over long time and might have leftovers etc. - if anybody experienced in that area can give good advices and suggestions, that could be improved.Regardless of that: As long as you assume, there is no need for handling concurrent access, there is no need for write access, as long as you do not want to update the XML DB itself - which was the initial question.
Not fully related, but just in case anybody else thinks about this:
I was doing similar but with similar approach in the past:
Using sync tool, I did a one way synchronization from the server share to a local folder like e.g. c:\data, including the catalog file and the cover art.
MyFilms config then used the local copy - whatever was changed, never touched the server file.
Big advantage:
The local copy was on local SSD drive, thus it was stunning fast for both opening/reading the catalog and the artwork (which takes some time, when you do that via network / NAS).
Yes, fully correct - reason see below.
It is all about finding a good compromise between safety, when accessing and/or changing data and locking. We don't want to lock too much, as otherwise GUI might have to wait too long in certain situations to finish certain methods - but we must makle sure, data is consistant.
So normal "read" access should NOT be exclusive and should NOT prevent other instances to perform actions (think about e.g. trakt updating in the background).
All this is even more complicated, if you access the DB file from multiple PCs - as you're not only in different threads, but not even in different tasks anymore. We had problems in the past, that the normal stream parameters did not work well for this - and if you leave windows (using NAS with SAMBA etc.), we can't be sure anymore, that the on board stuff works - that's why we use a locking file that is independant of the filesystem access API features (network access is different than local filesystem access).
However, quite possible, that this could be done in a better way - much of the code evolved over long time and might have leftovers etc. - if anybody experienced in that area can give good advices and suggestions, that could be improved.
Regardless of that: As long as you assume, there is no need for handling concurrent access, there is no need for write access, as long as you do not want to update the XML DB itself - which was the initial question.
