Skip to content

Support for stronger single-activation guarantee #2428

@sergeybykov

Description

@sergeybykov

Orleans temporarily violates the single-activation guarantee in certain failure cases preferring availability over strong consistency. In some scenarios applications are okay to trade availability for the simplicity of strong consistency. Today, strong consistency is achievable via external mechanisms, such as storage with etag support. This proposal is to add a mechanism and an extensibility point to formalize the pattern.

  1. Add a grain class attribute, e.g. StrongSingleActivation(TimeSpan leaseTime) that would indicate that before creating an activation of a grain of this type a lease has to be obtained by the runtime. A failure to obtain a lease will fail the activation process. A failure to renew the lease will trigger deactivation of the grain before the lease expires.

  2. Add a lease provider interface and a config option for defining lease providers.

public interface IGrainLeaseProivider
{
    Task<DateTime> GetLease(GrainReference grain);
    Task ReleaseLease(GrainReference grain);
    Task ReleaseLeases(GrainReference[] grains);
    Task<DateTime> RenewLease(GrainReference grain);
    Task<DateTime[]> RenewLeases(GrainReference[] grains);
}

Methods of IGrainLeaseProivider would return expiration UTC time(s) for the lease(s).
Catalog would be responsible for trying to renew leases, e.g. when a half of the original lease time elapses. We could start with a single renewal attempt, and add optional retries later. As part of the deactivation sequence, Catalog will make a best effort to release the lease.

A first lease provider could simply leverage Azure Blob leases. A more performant/scalable solution could leverage other consistency and leader election mechanisms.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions