Concurrency in Services

Please submit a patch for your use case so as we can review and add to services core.

Note this will only be added to drupal 6 as drupal 5 is feature frozen and please provide the code as a patch file.

Ivan and Marc,
I don't see any obvious reasons for adding generic semaphore support on the method granularity level. That is not to say that I don't see the point of semaphores and other concurrency strategies in general, but I think that the methods that use semaphores should take care of that on their own. The need for semaphores seems too rare to motivate it's inclusion in services, in most cases the method granularity is probably insufficient or wrong anyway.

What would make sense, to me at least, is to make a more general semaphore module. Complete with timeouts and all the other goodies. It would then fall to the service that is in need of semaphores to utilize this semaphore module as it sees fit, using whatever granularity level it wishes.

Cheers
/Hugo

Hugo

Thanks for your feedback andgiven your arguments I'm going to set this as won't fix simply because it isn't a service specific matter.

Marc

Ivan,
First of all I want to say that I don't disapprove of the semaphore functionality, nor do I have any serious reservations about your implementation. I think that it's great that you both have idéas and the talent to back them up with actual code.

But as it only is edge-cases that have the need for this functionality, and to repeat my previous argument: for most of those edge cases semaphores that use method-level granularity will not be satisfactory. What I propose, a separate semaphore module, is just as much a solution that is ready for use now. It only requires you to create it. Just make sure that you don't use variables for semaphores, but create a dedicated table instead. This is because all variables are loaded upon every requests, and setting variables all the time will prevent efficient caching of variables. In other words it will cause a site-global memory and performance hit.

What i envision is a module "semaphore" that essentially provides the following functions:

  /**
   * Function used to acquire a semaphore to lock common resources.
   *
   * @param string $name 
   * @return bool
   *  Returns TRUE if the semaphore was acquired, otherwise FALSE is returned.
   */
  function semaphore_acquire($name) {
    //...
  }

  /**
   * Function used to release a semaphore.
   *
   * @param string $name 
   * @return void
   */
  function semaphore_release($name) {
    //...
  }

Your service callback then just has to use this API.

  function _your_service_callback($arg1) {
    if (!semaphore_acquire('_your_service_callback')) {
      return services_error(t("'!method' service is busy. Please try again in a moment.", array('!method' => '_your_service_callback')));
    }

    //...

    semaphore_release('_your_service_callback');
    return $result;
  }

This way of doing it could just as easily cover the following scenario:

  function _your_service_callback_2($nid) {
    $semaphore = '_your_service_callback_2_' . $nid;
    if (!semaphore_acquire($semaphore)) {
      return services_error(t("The node !node is busy. Please try again in a moment.", array('!node' => $nid)));
    }

    //...

    semaphore_release($semaphore);
    return $result;
  }

...thus solving our granularity problem in one fell swoop.

Cheers,
/Hugo

Great! Looking at this has given me a lot of idéas re. services extensibility. There is a lot that needs to be done in this area. We'll need some more hook_alters to allow other modules that the active auth-module to alter the method definitions. I also think that we would need "#before call" and "#after call" attributes for methods, similar in function to the form elements #after_build. That would open up for augmentation by third party modules and help keeping services focused on core functionality.

Just holla when you've started on the semaphore module, then we'll see where we can take it.

/Hugo