Azure Functions: Singleton for expensive object

Question

I've created some very simple Azure functions. They read and write data from Couchbase (which is running in Azure on a VM).

I'm concerned about the connection(s) that I make to Couchbase in an Azure Function. I create a Cluster object each time. This is an expensive operation, and I would typically only do it once in a normal web app. But in the Azure Function, I'm newing it up every time.

There are a lot of expensive to instantiate objects like this beyond just Couchbase. Is there way to create a singleton, or some sort of shared object that Azure Functions can reuse between calls?

You can see a description of what I'm doing here: https://blog.couchbase.com/azure-functions-couchbase-server/
The full source code here: https://github.com/couchbaselabs/blog-source-code/tree/master/Groves/074AzureFunctions/src/CouchbaseWithAzureFunctions

Stephen Cleary · Answer 1 · 2018-02-12T03:34:17.820

When dealing with singletons on Azure Functions, there are several considerations. One is that global state is shared among AF invocations. So, if a function is invoked once and then again later (soon enough that the host hasn't unloaded your code), then the initialization only happens once. Another consideration is that AF is perfectly free to start multiple AF invocations simultaneously - so any singletons need to be threadsafe (including their initialization).

This means you'll want to use Lazy<T> / AsyncLazy<T>. However, bear in mind that AF (with these types) will preserve the singleton state (post-initialization) for your next invocation even if it fails. This can be a problem particularly with cloud computing because if there's a network (or configuration) error when your AF is starting up, you want the initialization to be retried on the next AF invocation.

In conclusion, you want to use Lazy<T> / AsyncLazy<T> in such a way that is threadsafe and does not preserve failures.

With Lazy<T>, this means you have to use the LazyThreadSafetyMode.PublicationOnly flag and pass a function to the constructor (not just implicitly use the default constructor for T). Note that this means you need to ensure your initialization function itself is threadsafe because it can be executed by multiple threads simultaneously.

With AsyncLazy<T>, you have to use the AsyncLazyFlags.RetryOnFailure flag. Since AsyncLazy<T> is essentially a Lazy<Task<T>>, the async initialization task is "shared" among all simultaneous callers, and then atomically replaced with a new Lazy<Task<T>> instance if it fails. So the async initialization function does not need to be threadsafe.

Since getting this all right (especially for multiple singletons) is rather copy-and-pasteish, I abstracted this out for the AF project I'm working on:

First I have a singleton abstraction to make the construction simpler and more uniform across sync and async singletons. My particular implementation uses AsyncLazy<T> for both sync and async singletons so that a sync initialization function will "share" its work, so it's only run once even if multiple threads simultaneously request an instance.
This abstraction is then used to create the actual static singleton instances, and then when the function is actually invoked, I resolve the instances at that time and register them with my DI container (in this case, SimpleInjector), also treating the DI container itself as a singleton.

It took a while to get to this point, but I'm pretty pleased at how it's turned out. Been meaning to blog about this, too...

Stephen thanks for the great answer. How about coming on my podcast sometime to talk about it, and promote your work :) — Matthew Groves, Sep 29 '17 at 14:46
@MatthewGroves: I'd love to, thanks! I got an error from the email form on your website, but feel free to email me - [my address is on my site](https://stephencleary.com/contact/). — Stephen Cleary, Oct 20 '17 at 13:32
The URLs in your answer are 404s now - any chance you could fix them or post the code in your answer? — Cocowalla, Feb 11 '18 at 15:17
If anyone's curious, we did record that podcast: https://crosscuttingconcerns.com/Podcast-072-Stephen-Cleary-on-Azure-Functions — Matthew Groves, May 03 '18 at 14:26

score 14 · Answer 2 · answered Sep 11 '17 at 20:21

Static properties for your expensive connection objects will work fine, but I recommend wrapping them in Lazy<> so that you get guaranteed thread safety out of the box.

Based on the sample blog post that you linked to an example of making the bucket reusable across all your function calls in a guaranteed thread safe way might look something like this:

public class FunctionClass
{
    private static Lazy<IBucket> LazyBucket = new Lazy<IBucket>(() =>
    {
        var uri = ConfigurationManager.AppSettings["couchbaseUri"];
        var cluster = new Cluster(new ClientConfiguration
        {
            Servers = new List<Uri> { new Uri(uri) }
        });

        var bucketName = ConfigurationManager.AppSettings["couchbaseBucketName"];
        var bucketPassword = ConfigurationManager.AppSettings["couchbaseBucketPassword"];

        return cluster.OpenBucket(bucketName, bucketPassword);
    });

    // Your actual function implementation
    public static async Task Run()
    {
        // Here you are guaranteed to get back a shared connection object to your bucket that has been
        // initalized only once in a thread safe way
        var initalizedOnceBucket = LazyBucket.Value;

        // do something with the bucket
    }
}

If the construction of your expensive object that should be shared relies on some async calls (I suspect the Couchbase C# client might have async versions of it's methods). You can use the AsyncLazy<> from the awesome Nito.AsyncEx Nuget package written by Stephen Cleary. Regular Lazy<> is built into .NET so don't require any external dependencies.

I wish I could give you both a checkmark. Thank you for your answer! — Matthew Groves, Sep 15 '17 at 19:06
No problem, Mikhail was here first and his answer is totally correct. Just wanted to chime in and show the patterns I use in my own functions — Jesse Carter, Sep 15 '17 at 19:08

Mikhail Shilkov · Accepted Answer · 2017-09-11T22:22:13.093

9

You can use the normal singleton, i.e. a static property which returns the single instance of something. As always, be careful with thread-safety, for example use Lazy<T> as @Jesse suggested.

You could also use a static constructor to do initialization before the first call to your Function is executed. Static constructor is thread-safe by definition.

In both cases, you'll be able to reuse the expensive stuff between all the calls that run on the same instance (server).

edited Sep 11 '17 at 22:22

answered Sep 11 '17 at 19:00

Mikhail Shilkov

34,128
3
68
107

3

Using Lazy<> or AsyncLazy<> along with static properties helps to mitigate any potential threading issues – Jesse Carter Sep 11 '17 at 20:25

Philip Johnson · Answer 4 · 2018-11-20T15:50:01.130

You can use the [Singleton] attribute on the Azure function itself to ensure that for example, queue functions are called synchronously. However if the thread then sleeps, the next queue item could be read. So I used this and also implemented the singleton pattern in my code around the expensive calls, to ensure that critical code was only executed once at any one time.

e.g.

[Singleton(Mode = SingletonMode.Function)]
[FunctionName("TimerFunction")]

Singleton pattern:

public sealed class PowerBiCapacitySingleton
{
    private static PowerBiCapacitySingleton _instance;
    private static readonly object Padlock = new object();

    private PowerBiCapacitySingleton()
    {
    }

    public static PowerBiCapacitySingleton Instance
    {
        get
        {
            lock (Padlock)
            {
                if (_instance == null)
                {
                    _instance = new PowerBiCapacitySingleton();
                }
                return _instance;
            }
        }
    }

    // code goes here
    ...
}

Azure Functions: Singleton for expensive object

4 Answers4