On Mon, Dec 23, 2013 at 1:44 AM, Mike Tutkowski
wrote:
> Yeah, at first I was thinking both simultaneous calls would succeed and two
> accounts would be created (this is what happens when two volumes with the
> same name are created because the volume ID is what really matters).
>
> However, with
Yeah, at first I was thinking both simultaneous calls would succeed and two
accounts would be created (this is what happens when two volumes with the
same name are created because the volume ID is what really matters).
However, with accounts, the first will succeed and the others fail, which
can b
What is the account creation logic on Solidfire SAN if you try to create the
same simultaneously? I am assuming there should be some unique constraint like
account name/id etc. Try to see if this can be utilised so that one of the
account creation call fails with appropriate error/exception.
-K
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 wrote:
> Mike - I think your
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+
I think just catching/handling the exception here will give you exactly
what you want. It doesn't eliminate the race but it mitigates any negative
impacts. Maybe change your logic to first "get_account", then based on
results you can do the create or not
On Dec 22, 2013 5:25 PM, "Mike Tutkowski"
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 acti
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 th
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
op
