What are best practices for synchronizing data access in web applications?

cpu...@gmail.com

unread,

Mar 1, 2022, 4:15:34 AM3/1/22

to golang-nuts

I've developed a semi-complex server application (https://evcc.io) with web ui. Since web requests are async per nature and I wan't to service them quickly, mutexes are used. I'm now at the point where I realise that sprinkling (un)locks over the code quickly leads to deadlocks and unforeseeable complexity.

What are good patterns to cope with that? Some I could imagine are:

- granular locks, maybe plus rigorous use of getters/setters

- some sort of synchronised data container (also eliminated unwanted/undetected access)

- clear naming scheme/separation of concerns

Are there any best practices/ talks/ presentations I could refer to?

Thanks,

Andi

Brian Candler

unread,

Mar 1, 2022, 5:00:12 AM3/1/22

to golang-nuts

I would ask what is the shared resource that you're synchronizing access to. If there's a backend database, usually the database API will have some sort of thread-safe connection pool, so presumably it's something else.

> Are there any best practices/ talks/ presentations I could refer to?

You haven't added channels to your list of patterns. I recommend you watch and digest "Rethinking Classical Concurrency Patterns" by Bryan C. Mills:

https://www.youtube.com/watch?v=5zXAHh5tJqQ
I found it very much worth the effort to fully understand the code examples included.

Andreas Götz

unread,

Mar 1, 2022, 12:25:58 PM3/1/22

to golang-nuts

> I would ask what is the shared resource that you're synchronizing access to.

The resource is really the internal program state. It's a steering mechanism controlled by various parameters (mode, timings etc) that need be synchronized to avoid races.

> I recommend you watch and digest "Rethinking Classical Concurrency Patterns" by Bryan C. Mills:

That's on my reading backlog, thank you for the youtube link.

> You haven't added channels to your list of patterns

Thought about them and discarded. I might make perfect sense to buffer all web input (using channels or whatever) until global lock becomes available. That way the entire main flow could be lock-less. I'll check the talk.