Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: unknown ~allinclude:_spf.google.com (athena.apache.org:
 encountered unrecognized mechanism during SPF processing of domain of
 jeff@greenqloud.com)
MIME-Version: 1.0
In-Reply-To: 
 <CACOnxCidZM2eUSfr_rU06X5fHOkvCFPwEsfd10RowrWnUOH2pw@mail.gmail.com>
References: 
 <CADOTMGGUCfJWE8j7Q4RB4MmMkYGDybf9M7Q6mhHG0YMP+s+wOA@mail.gmail.com>
	<CACOnxCgrPQKZokHXP01FwZPv1qze+3PRk-oj5qxNTRt2mn3Epw@mail.gmail.com>
	<CACOnxChbqDWjUu0hzX_WtC8bQ_a6YmAkoxe4mEDOXTLyzxq-iw@mail.gmail.com>
	<CACOnxCidZM2eUSfr_rU06X5fHOkvCFPwEsfd10RowrWnUOH2pw@mail.gmail.com>
Date: Tue, 3 Feb 2015 11:11:22 +0000
Message-ID: 
 <CADOTMGHvO+0O=-GM+4ZgOMct+njZPmWyZaBrfZ4Sh2j5qhXVOQ@mail.gmail.com>
Subject: Re: Database locking code
From: Jeff Hair <jeff@greenqloud.com>
To: dev@cloudstack.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I've tried this and from our testing thus far it appears to do the
job. In fact the synchronization code I wrote didn't really do the job
(was storing a bunch of single-threaded ExecutorServices, one per
user--but still noticed conflicts at the end).

One concern I have though is the management server and running out of
threads. Let's say 10 of these operations are submitted. They all get
blocked and execute one at a time, per user. If enough users submit
enough of these requests, what will happen to other requests that
don't need to be locked? I assume we can configure the management
server's thread pool size somewhere?

Jeff

On Thu, Jan 29, 2015 at 2:34 PM, Mike Tutkowski
<mike.tutkowski@solidfire.com> wrote:
> Like this:
>
>             GlobalLock lock =3D 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.tutkowski@solidfire.com> wrote:
>
>> I wrote that example code from memory, but now that I think about it, yo=
u
>> 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 an=
d
>> have a finally to unlock and release the lock.
>>
>> On Thu, Jan 29, 2015 at 7:27 AM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> Does this work for you?
>>>
>>>             GlobalLock lock =3D 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 D=
B
>>> lock");
>>>
>>>                 }
>>>
>>>                 // do your work
>>>
>>>             }
>>>
>>>             finally {
>>>
>>>                 lock.unlock();
>>>
>>>                 lock.releaseRef();
>>>
>>>             }
>>>
>>> On Thu, Jan 29, 2015 at 3:32 AM, Jeff Hair <jeff@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.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=3Dplay>*=E2=84=A2*
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=3Dplay>*=E2=84=A2*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=3Dplay>*=E2=84=A2*


--=20
Jeff Hair
Core Systems Developer

Tel: (+354) 415 0200
jeff@greenqloud.com
www.greenqloud.com