cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <>
Subject Re: Distributed locking mechanism?
Date Mon, 23 Dec 2013 02:04:11 GMT
Mike - I think your use case can be answered by Alex's wiki [1] - handling
locking section.		
You can look for where all the methods provided in Generic Dao (that end
in "InLockTable") is referred to get a better idea.



On 22/12/13 4:24 PM, "Mike Tutkowski" <> wrote:

>Yeah, if it were just a single management server, I could use
>"synchronized", but since it's not I was curious how we handle this
>Perhaps your recommendation in regards to using a database table is the
>to go here. Do you know of any code in CloudStack that performs this kind
>of action that I could use as a template?
>I actually looked into this SolidFire API more and - in this case -
>name must be unique in the SAN, so it's a non-issue (I thought like
>that account names could be reused and you would identify the one you want
>based on its unique ID only). Technically it's not really a non-issue,
>though. For example, two threads could try to create the same account at
>the same time, but one would get an exception (duplicate account name).
>That's OK, though. I could re-write the logic to catch the exception and
>look for the account again (if the account is there, you're OK; else,
>really is a problem).
>CloudStack doesn't need to know about SolidFire accounts, though (just my
>plug-in does). SolidFire has this kind of division in our SAN to support
>APIs that query for statistics based on a tenant's particular account.
>On Sun, Dec 22, 2013 at 2:40 PM, Marcus Sorensen
>> As far as I'm aware, most of this sort of thing is managed by the state
>> machines on the resources themselves, combined with the transactional
>> database to move between states it keeps the management servers in sync.
>> I'm not sure the problem is specific to having multiple mgmt servers.
>> have the same race with a single mgmt server, but having one makes it
>> easier to solve (e.g. via synchronize block).
>> There are probably many different ways to tackle this. My immediate
>> is that cloudstack needs to know about your external accounts if its to
>> expected to handle them. But I imagine you could also use any old
>> transaction to do what you want, maybe have your own accounts table you
>> lock.
>> Another option is simply to make the action idempotent. Why does
>> the same account twice result in two accounts? Can that be fixed?
>> On Dec 22, 2013 1:25 PM, "Mike Tutkowski" <>
>> wrote:
>> > Hi,
>> >
>> > I was wondering how we control access to shared resources that are
>> > utilized by different management servers at the same time.
>> >
>> > For example:
>> >
>> > When a user attaches a volume (that's based on the SolidFire plug-in)
>> a
>> > VM, my plug-in looks at the CloudStack account that is requesting the
>> > operation. If this CloudStack account does not have a corresponding
>> account
>> > on the SolidFire SAN, I must create one (there is a 1:1 mapping
>> > CloudStack and SolidFire accounts).
>> >
>> > How can I protect against a situation where my plug-in is running in
>> > multiple management servers and performing this kind of operation at
>> > same time (in other words, I don't want both instances of the plug-in
>> > see no SolidFire account and then they each end up creating one, which
>> > breaks the 1:1 mapping between a CloudStack account and a SolidFire
>> > account)?
>> >
>> > Thanks!
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e:
>> > o: 303.746.7302
>> > Advancing the way the world uses the
>> > cloud<>
>> > **
>> >
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>o: 303.746.7302
>Advancing the way the world uses the

View raw message