So you are locking the object in your middleware, thus making it impossible to have multiple requests being processed in parallel, because once a request is being processed the Lock is still locked blocking the next requests.
You library is a great one. Cache is mainly adopted when performance matter.
It s ok to say to the readers that for educational purposes you will lock on the middleware so they are aware it should not be the case in real world. But in prodcution/real world your locked section should me as small as possible.
Locking it only when it needs to be locked is how you should do it.
For example, why would you block other requests if one request is writing a response to the client?
Imagine a slow http client that reads 10 bytes per second from your server, that would make a 100 bytes request stay in processing state for 10 seconds. Thus the lock is locked of 10 second and no other request can be processed.
Again, I want to say that your library is great, I'm just stating the fact that locking in the middleware is not the best thing to do.
So you are locking the object in your middleware, thus making it impossible to have multiple requests being processed in parallel, because once a request is being processed the Lock is still locked blocking the next requests.
Hi! Thanks for your comment.
I wanted to stick with the standard library for this project.
From my research,
mapandcontainer/listare not safe for concurrent reading and/or writing.On every request, one or both of these structures are being updated so I thought I’d lock the cache per each access.
This was my first proper Go project and I’m eager to learn. Where would you make changes?
You library is a great one. Cache is mainly adopted when performance matter.
It s ok to say to the readers that for educational purposes you will lock on the middleware so they are aware it should not be the case in real world. But in prodcution/real world your locked section should me as small as possible.
Locking it only when it needs to be locked is how you should do it.
For example, why would you block other requests if one request is writing a response to the client?
Imagine a slow http client that reads 10 bytes per second from your server, that would make a 100 bytes request stay in processing state for 10 seconds. Thus the lock is locked of 10 second and no other request can be processed.
Again, I want to say that your library is great, I'm just stating the fact that locking in the middleware is not the best thing to do.
Ah, great. Thanks for explaining! I understand what you’re saying 👍🏻
I've updated the project and the article so that the mutex is inside the cache 😊