Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Reuse CloudBlobClient Object

I have these two objects for Azure Blob Storage access and want to use them in ASP.NET MVC application.

CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("Deesd");

My question is: Can I reuse the same instance of the objects across all the application requests, or should I instantiate a new object in every method?

like image 617
Registered User Avatar asked Mar 29 '12 21:03

Registered User


People also ask

What is ETag in blob storage?

An ETag property is used for optimistic concurrency during updates. It is not a timestamp as there is another property called TimeStamp that stores the last time a record was updated. For example, if you load an entity and want to update it, the ETag must match what is currently stored.

Is Azure storage blob?

Azure Blob Storage is Microsoft's object storage solution for the cloud. Blob Storage is optimized for storing massive amounts of unstructured data. Unstructured data is data that doesn't adhere to a particular data model or definition, such as text or binary data.

What is Azure Blob lease?

The Lease Blob operation creates and manages a lock on a blob for write and delete operations. The lock duration can be 15 to 60 seconds, or can be infinite. In versions prior to 2012-02-12, the lock duration is 60 seconds.

What is blob name in Azure storage?

Blob NamesA blob name can contain any combination of characters. A blob name must be at least one character long and cannot be more than 1,024 characters long, for blobs in Azure Storage. The Azure Storage emulator supports blob names up to 256 characters long.


2 Answers

You can reuse instances, just don't access the same instance from multiple threads concurrently because it is not thread safe.

UPDATE April 2019 (7yrs later)

NOTE: You should always consult the latest SDK documentation.

Yes, it is now (as of this update at least) safe to use CloudBlobClient and other objects in a thread safe manner in newer versions of the SDK. In fact, it is encouraged by some documentation that you find, but it is technically still not guaranteed to remain that way by design (e.g. future major versions of the SDK could reneg on this).

As usual, you should probably be providing an abstraction for your application level logic that hides the client and its lifetime as much as possible. Then you let the abstraction worry about lifetime management. Maybe that's using a simple static instance today, it's maybe using pooling tomorrow, but at least if there's a problem the majority of your application logic is abstracted from it. 👍

like image 113
Drew Marsh Avatar answered Oct 20 '22 04:10

Drew Marsh


You can reuse it. To my knowledge, it contains no state whatsoever beyond what it's initialized with.

like image 21
user94559 Avatar answered Oct 20 '22 04:10

user94559