2016-08-27 5 views
-1

동시성 제어에 대한 질문이 있습니다.열 업데이트 후 Java 개체 업데이트

다음은 시나리오입니다.

  1. 자바 API/스레드는 데이터베이스에서 엔티티/행을 읽습니다.
  2. 다른 스레드가 동일한 행을 업데이트합니다.
  3. 이제 1 단계에서 읽은 개체/행을 업데이트하려면 어떻게해야합니까?
+0

안녕 Suman; 조금 질문을 명확히 해 주시겠습니까? [Concurrency control] (https://en.wikipedia.org/wiki/Concurrency_control)에 대해 걱정하는 것 같지만 3 단계에서 어떤 일이 일어나기를 원하지는 모르겠습니다. 첫 번째 스레드를 두 번째 스레드의 업데이트를 덮어 쓰더라도 행을 업데이트 할 수 있습니까? 이를 Lost Update Problem이라고하며 고전적인 동시성 제어 문제입니다. –

+0

질문을 표현하고 형식을 지정하여 조금 더 가독성있게 만들었습니다. –

답변

1

격리 수준을 설정해야합니다. 도움이 될 수있는 아래의 예를 찾으십시오. 예를 들어, A, B 및 C 동시 프로세스 3 개가 있습니다. A는 트랜잭션을 시작하고 데이터를 기록하고 결과에 따라 커밋/롤백을 작성합니다. B는 단지 SELECT 문을 실행하여 데이터를 읽습니다. C는 데이터를 읽고 갱신합니다. 이 모든 프로세스는 동일한 테이블에서 작동합니다. T.

READ UNCOMMITTED - no lock on table. You can read data in the table while writing on it. This means, A writes data (uncommited) and B can read this uncommited data and use it (for any purpose). If A executes a rollback, B still has read the data and used it. This is the fastest but most insecure way to work with data since can lead to data holes in not physically related tables (yes, two tables can be logically but not physically related in real world apps =\). 
READ COMMITTED - lock on committed data. You can read the data that was only commited. This means, A writes data and B can't read the data saved by A until A executes a commit. The problem here is that C can update data that was read and used on B and B client won't have the updated data. 
REPEATABLE READ - lock on block of sql(which is selected by using select query). This means, B reads the data under some condition i.e. WHERE aField > 10 AND aField < 20, A inserts data where aField value is between 10 and 20, then B reads the data again and get a different result. 
SERIALIZABLE - lock on full table(on which Select query is fired). This means, B reads the data and no other transaction can modify the data on the table. This is the most secure but slowest way to work with data. Also, since a simple read operation locks the table, this can lead to heavy problems on production: imagine that T table is an Invoice table, user X wants to know the invoices of the day and user Y wants to create a new invoice, so while X executes the read of the invoices, Y can't add a new invoice (and when it's about money, people get really mad, specially the bosses). 

희망이 있습니다.