In addition to providing a locking mechanism across multiple instances of
the management server, GlobalLock also let me change my logic so that my
lock could be more fine grained (in this case, a different lock per
cluster).
On Tue, Jan 27, 2015 at 7:18 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> FYI: It appears this GlobalLock class is used pretty frequently in the
> codebase. I went ahead and replaced my synchronized logic with GlobalLock
> logic.
>
> On Tue, Jan 13, 2015 at 8:54 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> The use case is that I have access control lists on my SAN that I
>> dynamically update as a given volume is attached to or detached from a VM
>> in a cluster.
>>
>> Let's say multiple "attach" commands come in for VMs in the same cluster
>> (I use one ACL per compute cluster). This leads to the storage framework
>> calling grantAccess on my plug-in from different threads at the same time
>> (which leads to the plug-in "losing" one of the volumes that is supposed to
>> be in the ACL).
>>
>> If I use only one management server and protect grantAccess with a
>> synchronized block, the problem goes away (the ACL is always correct).
>>
>> I was looking to extend this synchronization across grantAccess calls
>> that are running in multiple management servers at the same time.
>>
>> On Tue, Jan 13, 2015 at 6:45 PM, Nitin Mehta <nitin.me...@citrix.com>
>> wrote:
>>
>>> Yes, it should do it for you. Please check for the references of this
>>> method and ensure there are other logic pieces using this.
>>> It might help if you can you give some context of of your use case ?
>>>
>>> Thanks,
>>> -Nitin
>>>
>>> On 13/01/15 4:12 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
>>> wrote:
>>>
>>> >Hi,
>>> >
>>> >I have code in my plug-in that I'd like to make sure doesn't run in
>>> >multiple threads at the same time.
>>> >
>>> >Of course if there were only the possibility of one management server
>>> ever
>>> >running at a time, then I could just use synchronized.
>>> >
>>> >What is the recommended CloudStack approach?
>>> >
>>> >I see code like this in places (in a try block):
>>> >
>>> > GlobalLock lock =
>>> >GlobalLock.getInternLock(templateIdPoolIdString);
>>> >
>>> > if (!lock.lock(5)) {
>>> >
>>> > s_logger.debug("Couldn't lock the db on the string
>>> " +
>>> >templateIdPoolIdString);
>>> >
>>> > return null;
>>> >
>>> > }
>>> >
>>> >Then the finally block has this:
>>> >
>>> >lock.unlock();
>>> >
>>> >lock.releaseRef();
>>> >Does this achieve what I'm looking for?
>>> >
>>> >Thanks!
>>> >
>>> >--
>>> >*Mike Tutkowski*
>>> >*Senior CloudStack Developer, SolidFire Inc.*
>>> >e: mike.tutkow...@solidfire.com
>>> >o: 303.746.7302
>>> >Advancing the way the world uses the cloud
>>> ><http://solidfire.com/solution/overview/?video=play>* *
>>>
>>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
