please support global locking

[vigouredelaruse]

assuming

• .net deployments will increasingly take advantage of orchestrators (like k8s) or azure app service or ec2 to host multinode deployments
• use cases exist for establishing lock boundaries that supercede the thread and extend to 'clusters' or literally global zones
• a set of trusted global or near global multi-node locking strategies can be agreed upon, including say cosmosdb global locks, or azure bob leases, or plugglable solutions chosen from the market including github
• a base of users with lock semantics needs targetting multi-node deployments

this is a suggestion aspire would help diminish locking ad-hockery by supporting the configuration of a global locking strategy, that if it doesn't exist already, or isn't planned in some document i haven't read

.net 9 is introducing new lock semantics that will join a cognitive loading set of locking strategies that all ignore multinode deployments

who will bell the cat

while thinking about belling the cat there's the de rigeur background material on fencing tokens, replica counts and inopportune wall-clock shifts very nicely introduced

• here in some documentation about the redlock algorithm
• and this discussion on the ways and means of using storage backends ill designed to support distributed locks

with that said here is offered a more rigorous problem statement

who

developers continue to rely on thread locking strategies and vendors continue to support such workflows with language intrinsics and framework extensions

what

thread locking strategies are usually employed to synchronize access to resources, otherwise known as gating a workflow activity sequence

unfortunately thread locking semantics represent a fossilized layer of computer science, dated to a time when solutions were needed to synchronize multiple threads, as opposed to the current condition where solutions are needed to synchronize multiple threads running in multiple hosts each running on multiple nodes that do not necessarily coexist within a uniform time zone

why

domain specific distributed locking strategies exist, chiefly known to database administrators. however a team seeking a single entrypoint into an ecosystem of cross-platform generalized distributed locking strategies will currently look in vain

where

microsoft is positioning a new development time resource orchestration model with aspire that can serve as an entry point into a distributed locking ecosystem

how

aspire offers extension points that permit
* abstraction of resource configuration and composition used for rendering service definitions
* abstraction of resource consumption by client code

to be successful it's suggested here that the proposed global locking abstractions must needfully normalize the locking semantics of the supported strategies according to the underlying global locking best practices, as well as simplify the best practice supporting devops

from this planning repo readme

regards

[davidfowl]

This is outside the scope of what aspire has on its roadmap but would love to see others try to build this on top of whatever lower level building blocks aspire provides

[vigouredelaruse]

thanks for the thinktime @davidfowl - i'll take your comment as a sanity checked provisional pass on the initial assumptions

i just took a look at the current state of the aspire workload and it seems to me that a purported global locking configuration strategy

• could be delivered as a project template along the lines of the canonical aspire apphost and service defaults. please correct me if this is hallucination
• it's hard to imagine getting away with implementing a global locking feature without discovering the need to write some code

one forseeable need would be the need to map the configuration options as presented in the project template to the configuration options as required by the configured lock strategy. docker packaging could help here to bring shrinkwrapping to the supported strategies, and give the straetgy implementers a delivery shim into the ecosystem

is this continuing to make sense?
thanks

[davidfowl]

I dont think it would be a project template, I think it would look more like a hosting + client integration. What aspire enables you to do is build libraries/frameworks that have "infrastructure setup" logic. The application code is in a client integration and the infrastructure setup is part of a hosting integration. On top of that, hosting integrations can be used to configure deployment requirements for the library/framework.

If your lock abstraction had a reliance on cosmos, that could all be abstracted or configured by shipping 2 libraries.

[vigouredelaruse]

and the infrastructure setup is part of a hosting integration

reading further in the docs i believe that we are discussing

• activities transpiring in this repository https://github.com/CommunityToolkit/Aspire
• as per this documentation https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/integrations-overview

could all be abstracted or configured by shipping 2 libraries.

further it seems that we are discussing the 2 libraries in question

• mentioned here https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/integrations-overview

If your lock abstraction had a reliance on cosmos, that could all be abstracted or configured by shipping 2 libraries

this seems to suggest that the abstraction surface grows by 2 libraries per supported multinode locking strategy.

if true it seems to also suggest no need for an aspire global lock configuration strategy to aggregate the supported strategies, but rather handle each as a separate shipped product. is this a valid statement?

thanks again