Hi,
That looks like it will work for my purposes. When I have the time to
continue the task I was working on yesterday I will try this way.
Jeff
On Thu, Jan 29, 2015 at 2:34 PM, Mike Tutkowski
<mike.tutkow...@solidfire.com> wrote:
> Like this:
>
> GlobalLock lock = GlobalLock.getInternLock(
> someStringYouMadeUpThatIsUniqueForThisPurpose);
>
> if (!lock.lock(timeoutInSeconds)) {
>
> s_logger.debug("Couldn't lock the db on the string " +
> someStringYouMadeUpThatIsUniqueForThisPurpose);
>
> throw new CloudRuntimeException("Couldn't acquire DB lock");
>
> }
> try {
>
> // do your work
>
> }
>
> finally {
>
> lock.unlock();
>
> lock.releaseRef();
>
> }
>
> On Thu, Jan 29, 2015 at 7:32 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> I wrote that example code from memory, but now that I think about it, you
>> wouldn't call the lock method in the try block.
>>
>> Call lock and if you're successful, entry a try block to do your work and
>> have a finally to unlock and release the lock.
>>
>> On Thu, Jan 29, 2015 at 7:27 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Does this work for you?
>>>
>>> GlobalLock lock = GlobalLock.getInternLock(
>>> someStringYouMadeUpThatIsUniqueForThisPurpose);
>>>
>>> try {
>>>
>>> if (!lock.lock(timeoutInSeconds)) {
>>>
>>> s_logger.debug("Couldn't lock the db on the string
>>> " + someStringYouMadeUpThatIsUniqueForThisPurpose);
>>>
>>> throw new CloudRuntimeException("Couldn't acquire DB
>>> lock");
>>>
>>> }
>>>
>>> // do your work
>>>
>>> }
>>>
>>> finally {
>>>
>>> lock.unlock();
>>>
>>> lock.releaseRef();
>>>
>>> }
>>>
>>> On Thu, Jan 29, 2015 at 3:32 AM, Jeff Hair <j...@greenqloud.com> wrote:
>>>
>>>> I have some code I've added to CloudStack that I am currently
>>>> synchronizing on in the traditional manner (synchronized block,
>>>> ExecutorService, etc). I'm currently running a single instance of
>>>> CloudStack so I don't have to deal with clustering.
>>>>
>>>> I've read the Data Access Layer documentation and am wondering if the
>>>> database locks are the actual appropriate solution rather than what
>>>> I'm doing.
>>>>
>>>> Basically my issue is that I need to lock access to an IP address
>>>> reserved to the account and perform some long operations on it. I also
>>>> need to guarantee that no other IPs on the account are manipulated
>>>> while performing this task. Synchronization accomplishes this because
>>>> I can force the IP operations through an ExecutorService, but I'm
>>>> really looking for a better solution that will also work with
>>>> clustered management servers.
>>>>
>>>> Thanks,
>>>>
>>>> Jeff
>>>>
>>>
>>>
>>>
>>> --
>>> *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>*™*
--
Jeff Hair
Core Systems Developer
Tel: (+354) 415 0200
j...@greenqloud.com
www.greenqloud.com
