0001080: Playlist Concurrency issues

Relationship Graph

Viewing Issue Simple Details
ID	Category	Severity	Reproducibility	Date Submitted	Last Update
0001080	xmms2d	minor	always	06-08-30 00:58	09-10-14 21:54

Reporter	teh_fng	View Status	public
Assigned To
Priority	normal	Resolution	open
Status	feedback

Summary	0001080: Playlist Concurrency issues
Description	There are several concurrency issues with the any of the basic operations (remove, insert, move, etc.) that operate only on a position. Here is a proposed solution.
Additional Information	If two clients attempt to remove the same file simultaneously, then two files will be removed, but one will not be the intended file. The situation becomes more hairy when one client removes a file and a second client moves a file to the position of the file that client one is attempting to remove. In this case, the file that client 1 attempted to remove will not be removed, but the file that client 2 moved WILL be removed. Either situation could occur if two friends are building a playlist on separate computers while connected to xmms2d on their media pc in the living room. This solution assumes that the following operations are atomic: 1) remove (single file) 2) update (of file metadata) 3) add (append) 4) insert (or move) Additionally, this solution will require client session tracking. This could be accomplished with something like hardware hash + pid for a stateless connection. Now, for the solution: There will need to be a reference counted Master Playlist (MP). There will need to be a server side view of what the client sees (client playlists, or CP). Here is a simple example of these tables: realposN = correct position in clients' playlist MP ----- 1) File 1 (MPuid1, file uid1, realpos1) 2) File 2 (MPuid2, file uid2, realpos2) - marked for deletion 3) File 3 (MPuid3, file uid3, realpos3) - marked for deletion 4) File 3 (MPuid4, file uid3, realpos2) 5) File 4 (MPuid5, file uid1, realpos3) CP1 (out of sync) ----- 1) MPuid1 2) MPuid2 3) MPuid3 CP2 (in sync) ----- 1) MPuid1 2) MPuid4 3) MPuid5 Note: MP can be unordered. It's fine to sort it occasionally and optimize in other ways. Now, for the operations themselves: Remove -------- 1) Single file 'x' removed by client 'n' - MP[x] is marked for deletion and refcount updated, but not removed till reference count reaches 0 - CP[n] is updated - all operations for clients other than n will fail on file x (except for remove) 2) Range - Call single file remove n times 3) Overlapping ranges (two clients removing simultaneously) - Call single file remove n times Update (metadata) -------- 1) the file is marked for deletion - update the metadata - sync the client view - avoids a failed return code 2) the file exists in multiple locations and is marked for deletion - update the metadata - refresh all matching uids (potentially appending to the master table and marking the old files for deletion, but this shouldn't be necessary?) - sync the client view - avoids a failed return code 3) the file is NOT marked for deletion - no change 4) the file exists in multiple locations and is NOT marked for deletion - update the metadata - refresh all matching uids - sync the client view Add (append) ------------- no change Insert (or move) ----------------- 1) client playlist is current - append new entries to MP 2) client playlist is stale (out of sync) - sync by decrementing the refcount for all files marked for deletion - now the client playlist is current, continue with 1) above Sync ------- Sync operations decrement the refcount of files marked for deletion if the client's view is stale AND the file exists in the client's view. Also, we increment the reference count if the client's view is stale AND the file does NOT exist in the client's view. The new playlist sent to the client consists of all files NOT marked for deletion. I'm not sure if the client/server model is pull or push, but this should work in either case? Comment.

Mantis 1.1.6[^]