#14 Avoid concurrent access on burrows

burrows (1)
Olivier Azeau

There's a flaw in the current OpenNab architecture : each burrow data is loaded at the beginning of an http request and saved at the end of the request.
However, 2 calls can occur simultaneously for the same burrow. For instance, a rabbit ping and an api call.
This could lead to unexpected behaviour if we fall into sequences such as :
1- api load burrow
2- ping load burrow
3- ping save burrow
4- api save burrow
The data saved in 3) would be lost.

This issue is tricky because it might not occur so often so we might not want to load *every* http request with the burden of a locking mechanism.


  • Herman Kuiper
    Herman Kuiper

    Logged In: YES
    Originator: NO

    How much would flock() be of a burden? Burrows need to be on a FAT32/NTFS or non-NFS drive for it to work.

    W.r.t. performance when we're talking open servers for many:
    - in such a case I would recommend providing opennab on a server which
    would be able to handle the load, and
    - I don't think the load will be *that* high - mostly simple ping requests
    which do not need to lock the burrow - only when a plugin does a save on
    a burrow we could lock it