0

I am developing a e-commerce web app using Spring , Hibernate and MySql.

For ex : In this app at the time of placing order for products , I am going to update Product table record , means going to reduce product count from this table. I am using mysql update query for that. Its working fine . but if I send 100 of request at a time then that product count is not decreasing properly.

For that I got two answer

  1. I used messaging queue(RabbitMQ) to queued all request and reduce the count one by one

  2. I have to use hibernate lock

So I need to know other possible way to do that work and from above two way which one is good ?

Amit Patel
  • 134
  • 2
  • 17
  • 1
    Also optimistic locking and transaction isolation lvl serializable https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html. Queue can introduce another racing condition when there is pending 100 updates and you will read from the db in meantime. Also mysql has something called SELECT FOR UPDATE – Antoniossss Sep 10 '16 at 10:08
  • thanks, its really helpful ,I may use "SELECT FOR UPDATE ". but I have another problem here. suppose thread1(request1) select * from Product where productId=1 . thereby preventing Thread2(request2) from selecting same product .here my doubt is that , will thread2 wait to complete the updation of thread1 or Exception will be occurred. and if exception occur then how I will process the thread2 when thread1 processing completed . – Amit Patel Sep 10 '16 at 13:22
  • An exception will not occur unless the wait period is achieved (typically 50 seconds or so). Look at this answer of mine [Here](http://stackoverflow.com/a/38079598) for `FOR UPDATE` Intention Locks and look at the Sample Code chunk. Thread 2 waits until the Thread 1 `COMMIT` (thus blocking at Line2). So the point is to make that `START TRANSACTION` and `COMMIT` chunk tight and uber fast. So in Summary on Sample Code, Thread2 blocks while Thread1 has achieved Line2 but has not committed yet in Line5. Once Thread1 has done the `COMMIT`, Thread2 is freed and has successfully achieved Line2. – Drew Sep 10 '16 at 15:18
  • 1
    But if u assume that transactions are considered atomic and non-long running, than thread await will be minimal. ms wait on db lock is a fair tradeoff for 100% data consistency guarantee. – Antoniossss Sep 11 '16 at 05:49

0 Answers0