Let me preface this problem with the following: I’ve only tested this using the storage emulator. (SDK 1.5.)
Using a quickly built console app and local storage emulator, I created a fail scenario to test how a blob lease behaves upon the application exiting ungracefully. In the Azure production version, it would be in the form of multiple web role instances accessing the single blob and locking it via leases. I’ve had web role instances fail out, so I figured this would be a good test scenario.
The app acquires the lease on a particular blob, hits a break point before the lease release and I manually kill the console app. When I re-run the console app and try to acquire a new lease, I get the conflict error 409. This behavior is even exhibited quite some time after the first lease acquisition (and ungraceful exit).
I know, I know… I should just push it out to the cloud and see what happens, but I haven’t had the opportunity yet.
Is this behavior simply a case of the wacky storage emulator or will Azure behave the same way?
If it is more than 2 mins, it is likely just the emulator. Under 2 mins, I would expect the lease might not be available to be acquired (without forcing it). I have actually never tested this in the emulator, but it works great in the cloud…