Ways to mitigate locking issues caused by network latency

ELAN
1

Hi Han, following on from our previous post Is it possible for ELAN to work with a read-only and a writeable version of the same corpus?, we’ve now set up our site and tested various aspects of it. We intend to be able to access the BSL corpus remotely from this site while still taking advantage of ELAN’s file locking capabilities. This introduces an element of latency.

One thing we noticed was a locking race condition due to sync latency, happening when the same EAF was opened at the same time by multiple users. In this case both users gain access, with the second lock to enter the shared site location getting renamed by the site itself to avoid conflict.

While the latency itself is par for the course and the simultaneous opening rare, we were wondering what mitigation could be put in place. For example one solution could be to have the ELAN client, after a set period of time, check back on any locks associated with the currently opened EAF file, and raise a warning accordingly.

We’d greatly appreciate your thoughts on this.

-Xifong

2

Hi Xifong,

That is an interesting problem, I’m not sure if we can do much about this. The approach you propose might work, might be a lot of work, possibly leading to messy code, and it might easily fail. ELAN would only be able to check back on one lock file (it doesn’t know about others) and check its contents and that might be sufficient to detect if the lock may be unreliable, but that seems a lot of overhead for hopefully rare occasions.
Would it be possible to configure the site such that it doesn’t create a second renamed lock file but throws an error instead?

Anyway, I’ll make a note of this and add it to the request list.

-Han