You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Jeff Hair <je...@greenqloud.com> on 2015/02/03 12:11:22 UTC
Re: Database locking code
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
<mi...@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.tutkowski@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.tutkowski@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 <je...@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=play>*™*
>>>
>>
>>
>>
>> --
>> *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=play>*™*
>>
>
>
>
> --
> *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=play>*™*
--
Jeff Hair
Core Systems Developer
Tel: (+354) 415 0200
jeff@greenqloud.com
www.greenqloud.com
Re: Database locking code
Posted by Mike Tutkowski <mi...@solidfire.com>.
Does anyone know where such a setting might be stored (maximum number of
threads the job queue can use at a time)?
Thanks!
On Tue, Feb 3, 2015 at 4:11 AM, Jeff Hair <je...@greenqloud.com> wrote:
> 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
> <mi...@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.tutkowski@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.tutkowski@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 <je...@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=play>*™*
> >>>
> >>
> >>
> >>
> >> --
> >> *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=play>*™*
> >>
> >
> >
> >
> > --
> > *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=play>*™*
>
>
>
> --
> Jeff Hair
> Core Systems Developer
>
> Tel: (+354) 415 0200
> jeff@greenqloud.com
> www.greenqloud.com
>
--
*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=play>*™*