Probably misunderstanding of the Threading/Lock code

[Cameron Simpson]

On 22Sep2012 20:27, chris coleman <christocoleman at yahoo.com> wrote:
| | This code:
| |   x1 = LocalStatusFolder(name, repo)
| |   x2 = LocalStatusFolder(name, repo)
| | 
| | is the problem: if that _really_ occurs (create an object for the same
| | LocalStatusFolder more than once) then LocalStatusFolder needs to become
| | a factory function to return a previous instance if the name is reused.
| 
| Thanks to X and Cameron for finding this.
| 
| I agree with the upgrading to a Factory pattern here, replacing the
| current code which appears to be vulnerable to a race condition bug
| while OLI is running in multi threaded mode.  A race condition would
| possibly corrupt data in the LocalStatus, LocalStatusSQLite, and UIDMaps
| local databases/files.

Of course, the factory needs its own lock as well...

| While we're at it- why not upgrade UIDMaps to SQLite ?  Seems like
| it should be a higher quality solution than the flat file...

That depend how it is used (I've not read the code). If the UIDMaps are
read completely and rewritten completely (or simply appended to),
they're probably performant as they are. You only want something more if
you're doing ad hoc updates and so forth. And SQLite incurs a whole SQL
parser and locking bottlenecks all of its own.

In short, SQLite may be clunky overkill in this case, but I speak in
complete ignorance of the code here.
-- 
Cameron Simpson <cs at zip.com.au>

remember, information is not knowledge,
knowledge is not wisdom
wisdom is not truth
truth is not beauty
beauty is not love
love is not music
music is the best       - frank zappa