Great, thanks, everyone. Although I can get around this particular issue without the "InLockTable" this time, "InLockTable" is really useful to know as I can see it coming into play with other actions I may need to take.
On Sun, Dec 22, 2013 at 7:04 PM, Nitin Mehta <nitin.me...@citrix.com> wrote: > 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. > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Data+Access+Layer > > Thanks, > -Nitin > > On 22/12/13 4:24 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> > 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 > >situation. > > > >Perhaps your recommendation in regards to using a database table is the > >way > >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 - > >account > >name must be unique in the SAN, so it's a non-issue (I thought like > >volumes > >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, > >there > >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 > ><shadow...@gmail.com>wrote: > > > >> 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. > >>You'd > >> 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 > >>thought > >> is that cloudstack needs to know about your external accounts if its to > >>be > >> expected to handle them. But I imagine you could also use any old > >>database > >> transaction to do what you want, maybe have your own accounts table you > >>can > >> lock. > >> > >> Another option is simply to make the action idempotent. Why does > >>creating > >> the same account twice result in two accounts? Can that be fixed? > >> On Dec 22, 2013 1:25 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com > > > >> wrote: > >> > >> > Hi, > >> > > >> > I was wondering how we control access to shared resources that are > >>being > >> > 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) > >>to > >> 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 > >>between > >> > 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 > >>the > >> > same time (in other words, I don't want both instances of the plug-in > >>to > >> > 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: 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> *™*
