IMatch Anywhere 2018 Sneak Peak - Multi-user Concurreny and Locking

[Mario]

IMatch Anywhere WebViewer 2018 enables users to modify metadata directly in the browser. Rating, label, titles, descriptions, keywords and more.

For an application which is designed to be used by multiple users at the same time (concurrently) this creates a few additional problems which needs to be handled.
For example, what happens if two users try to change the metadata of the same file at the same time? This could lead to unexpected or even nasty effects and cannot be allowed.

IMatch Anywhere WebViewer uses locking to prevent this. When you select a couple of files and open the FileLens to view and edit the file data, these files are automatically locked in IMWS. This means that no other user can perform operations with these files while you are working on them. When you close the FileLens, all locks are released and other users are free to modify the files again.

The same happens in the Viewer, when you change something via the dashboard (e.g. a rating or label). The Viewer, tuned for speed, works a bit differently than the file lens. It does not lock the file when it is viewed, but when you first make a change. This means that if you are just viewing files, nothing is ever locked, which increases performance and reduces the change of users blocking each other.

If you attempt to make a change in the Viewer and the file is already locked by another user, you see a message like this (same in the FileLens):



These mechanisms are internally more complex than I dare to explain here. But being able to handle such things is why the big multi-user DAM systems cost so much money. Eh, wait...if IMatch Anywhere 2018 can do that too, why is it still so cheap? 

[jch2103]

Excellent! I know this is very challenging, so bravo!

[Jingo]

I'm sure you thought of this - but are the locks "auto-released" or cleaned up if the browser happens to crash in the middle of editing or after a long time frame of holding a lock? Also, is there any thought to allowing "pre-emption" of the lock if perhaps it has been longer than a given block of time?  Adding in the user details (username/client) might help in settings where someone needs to contact that user to see if they are still making an edit if pre-emption is not allowed? 

I work on hospital information systems that are client/server based and locking are a MAJOR part of keeping multi-user environments running smoothly... especially with patient data.  Pre-emption and proper lock handling when things "go badly" are critical to keeping data flowing... can't tell you how many times we get reports from users of a lock and upon investigation by the site (because they have the user/client info), they find the user went home for the day while an edit is in process... and the pre-emption mechanism saved the day because the new user could take over the lock and continue working (the original user edits are discarded).

Just my thoughts!

[Mario]

I'm sure you thought of this - but are the locks "auto-released" or cleaned up if the browser happens to crash in the middle of editing or after a long time frame of holding a lock?

If the browser crashes or the user closes the browser, the session will expire after the timeout you specify in the IMWS config (default: 20 minutes). This also releases all locks associated with that session.

Also, is there any thought to allowing "pre-emption" of the lock if perhaps it has been longer than a given block of time? 

No. By intention. I'm not trying to model a massive concurrent-user software here which needs to handle dozens of users competing for the same resources simultaneously. Actually, I assume that such a scenario is pretty much unlikely.

+ If a user leaves the browser open without 'using' IMatchWebViewer it logs the user out after 20 minutes. Releasing all locks automatically. User needs to log in again.
+ If the user navigates to somewhere else (in the same tab), IMatch WebViewer releases the locks.
+ Unused sessions expire in IMWS automatically after (default) 20 minutes, releasing all locks.
+ Locks are currently only held when the FileLens is open (for the selected files) or when the user works with the Viewer (for modified files).

I think that, in typical environments. users trying to modify metadata for the same set of files at the same time is very low.
And even if it happens occasionally, colleagues or family members can come up with simple solutions like "I'm working on the images in folder X / Category Y, leave them alone".

IMWS is currently not revealing the lock holder(s) (user name(s)) for privacy reasons. This can be added later if this really becomes a problem.

IMatch Anywhere and IMatch WebViewer are (almost) zero support products (judging by the number of sales and the emails I get / postings here). Keeping it simple is probably the main reason why this is so. I want to keep it that way 

[Jingo]

Thx for the info Mario...!