Race condition issue

[nhaancs]

service/business/domain/productbus/productbus.go

Line 119 in c3a19bf

func (b *Business) Update(ctx context.Context, prd Product, up UpdateProduct) (Product, error) {

I think the Update method has a potential race condition because it performs the update operation in two separate steps: query and update. This creates a potential time window between reading and writing where another transaction could modify the same product.

[ameghdadian]

Both operations(query and update) are performed in a single transaction:

service/app/sdk/mid/transaction.go

Line 16 in c3a19bf

func BeginCommitRollback(log *logger.Logger, bgn sqldb.Beginner) web.MidFunc {

Considering a transaction has ACID properties, two transactions are not likely to affect each other(Isolation property). So I think there should be no problem.

[nhaancs]

Both operations(query and update) are performed in a single transaction:

service/app/sdk/mid/transaction.go

Line 16 in c3a19bf

func BeginCommitRollback(log *logger.Logger, bgn sqldb.Beginner) web.MidFunc {
Considering a transaction has ACID properties, two transactions are not likely to affect each other(Isolation property). So I think there should be no problem.

Hi @ameghdadian, I dont see the project use the transaction middleware for product update route.

service/app/domain/productapp/route.go

Line 35 in c3a19bf

app.HandlerFunc(http.MethodPut, version, "/products/{product_id}", api.update, authen, ruleAuthorizeProduct)

Even they are executed in a transaction, other transactions can possibly read the the old value of the product if you haven't set the right isolation level in the database settings.

[ardan-bkennedy]

Updates are what udpates are. To minimize locks you need to just accept the last update in sets the state of the Database. That is why you need to pull a fresh version of the database's state before you do the update. You must make sure what you are updating is valid state.

I've worked on patient systems where they would "LOCK" a patient record at the application level and would not allow more than one person to get that lock. Sounds good right? NO. Now that person with the LOCK goes to lunch, walks away for hours, and no one else can service that patient record.

How we implemented the update is valid for this system.

But for sure someone could have started an edit 4 days ago, have several updates happen in front of them, then they can apply their update and the state of the DB would be that last update.