Correct me if I'm wrong, but wouldn't a functional "non-blocking database
access" implementation be a lot simpler than what's been discussed here?
The issue is that some database operations are interruptible, although it's
more efficient for them to not be done incrementally. Library-rescan, and
playlist/crate import where the imported playlist-file has a lot of tracks that
aren't already in the database, seem to be the two biggest cases, and both
involve adding lots of entries to the "library" table.
It seems to be that implementing this feature boils down to this:
1) Clean up the src/library/dao layer so that each DAO object only
accesses/modifies one table directly.
2) Any table that can remain locked for a long time (just "library"?) gains
some internal logic that allows writers to run unimpeded unless there are
readers, in which case the batch-write operation is committed, all the readers
are allowed to do their thing, then the batch-write operation continues.
This is much simpler than a separate thread, and accomplishes the same thing.
Steven Boswell
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
