Hey gophers, I wanted to know if there would be any solution / design pattern for the problem I'm facing. I have a system something like below..
I have one package(consumer) which is handling a http request. One package(dbClient) which is like a copy of DB and also a middleware between the first package and db. The functionality is, the consumer has an object of dbClient created.. and dbClient has copy of DB created in it. Every time consumer wants to access the DB, using the dbClient object it fetches the local data and accesses the data, and optionally might update the data. dbClient knows when the data is updated and it should update the data in actual DB. Now comes the concurrency part. Since consumer is processing each http request in separate goroutine, there can be concurrent data access in dbClient. So dbClient defines that while accessing the data the consumer should use the context of the goroutine which is accessing the data. So when *GetData(ctx context.Context)* is called on dbClient, it internally takes a lock on data, and returns the data. When the data is changed, internally a property in data will get changed to indicate the data was updated. So the job of dbClient is to release the lock, and update the DB, when the ctx is done. So the main idea is consumer should not have to explicitly take lock on the data. Any idea on how to tackle this? I'm thinking in this direction.. We will have one goroutine monitoring over slice of contexts. Each iteration it checks if any context is done and then releases the corresponding lock. At the end of each iteration, it updates the slice. And when GetData is called, dbClient will add the <ctx, lock> to that slice. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6d89bfcf-c386-4eeb-8557-a79b002e7b02n%40googlegroups.com.
