In a federated context, the go-fed library uses mutexes associated with specific IRIs before running associated business logic. However, this still doesn't prevent sql transactional conflicts at the service layer since it is not aware of mutexes. This can lead to transactional conflicts, which are not currently addressed. There are some different ways of approaching this:
Make a conceptual layer above service aware of the mutexes to lock in advance. I don't like this due to the open-ended nature of client code, which can lead to a leaky abstraction via opaque deadlocks. No fun for anyone.
Do not actually lock any mutexes in federated contexts, and introduce transactions instead into federated contexts, so that everything is tx-based, as Contexts can map 1 request to 1 tx. So a tx conflict is simply a matter of re-trying all the logic since that mapping is instantiated.
Refactor go-fed/activity to be transaction-aware instead of mutex-based, but as seen above, we can in theory make our implementation of go-fed/activity tx-based instead of mutex-based. I'm not confident a refactor of go-fed/activity to be tx-based would permit the lightweight mutex-based approach (which has its own benefits like enabling lightweight apps such as the testsuite).
It's labelled as a feature enhancement right now because it should result in a stability improvement in case of high sustained QPS / burst of QPS.
In a federated context, the go-fed library uses mutexes associated with specific IRIs before running associated business logic. However, this still doesn't prevent sql transactional conflicts at the
servicelayer since it is not aware of mutexes. This can lead to transactional conflicts, which are not currently addressed. There are some different ways of approaching this:serviceaware of the mutexes to lock in advance. I don't like this due to the open-ended nature of client code, which can lead to a leaky abstraction via opaque deadlocks. No fun for anyone.Contextscan map 1 request to 1 tx. So a tx conflict is simply a matter of re-trying all the logic since that mapping is instantiated.go-fed/activityto be transaction-aware instead of mutex-based, but as seen above, we can in theory make our implementation ofgo-fed/activitytx-based instead of mutex-based. I'm not confident a refactor ofgo-fed/activityto be tx-based would permit the lightweight mutex-based approach (which has its own benefits like enabling lightweight apps such as the testsuite).It's labelled as a feature enhancement right now because it should result in a stability improvement in case of high sustained QPS / burst of QPS.