Locking on BigIP

Unfortunately, there isn't an easy way to do this as all calls are treated independently. But, iControl is implemented as a single FIFO queue so you can be assured that if you issue two requests, they will not be executed side-by-side but one will always execute to completion before the other.

 

 

So, for you situation, what I would do would be to code the calls to create the objects and catch the SOAPFault on error. If you method to create receives a fault (most likely from the object already existing), you could look into the faultdetails as to whether the object already exists. If you want to verify further, then you can always call one of the query methods to determine whether it does indeed exist. and then move on.

 

 

So, the pseudo-code would look something like this:

 

 

call create
if success 
  proceed
if soapFault
  if soapFault->soapDetails contains exists
    optionally verify object exists already
    proceed
  else
    error condition

 

 

This seems easier than inducing a self-imposed sleep which may or may not yield this race condition anyway.

 

 

-Joe

 

Another option I just thought of might work as well. You could use the Management::DBVariable interface to create a "locking" variable implemented as a record in the configuration database. The DBVariable sample in the SDK shows how to list, create, delete, get and set database variables.

You could then from your nodes, query this values existence. If it's not set, then set it and do your work. Something like this:

set lock = value-of icontrol.lock varaible
if error 
  create icontrol.lock variable with value of 1
  do work
  delete icontrol.lock variable
else if lock == 0
  set icontrol.lock variable with value of 1
  do work
  delete icontrol.lock variable
else if lock == 1
  sleep and try again

With this approach there is still a chance of a collision if parallel requests are going in at the same time. Both could query the value of the variable at the same time and fall into the same condition.

Not sure which will work better for you but this will give you a couple of options.

-Joe

Thanks for your replies Joe. I think we will go with the first option though since the second option may still cause deadlocks. We did think of the first option ourselves but were not sure if it was the most clean way to go.

 

I guess the one thing we are going to have to count on is that the messages on the SOAP faults for certain actions remain almost same(atleast parts of it) and we can then compare messages. Two nodes independently connect to BigIP and each has its own iControl, hence the original reason for this post.

 

Thanks anyway!