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> >**
