2011-09-11 4 views
3

트랜잭션과 관련하여 ACID 속성을 수행 중이었고 다른 사이트에서 아래 문을 발견했습니다. ACID는 트랜잭션이 보장하는 네 가지 속성 인 원자 성, 일관성, 격리 및 내구성의 약자입니다.트랜잭션의 ACID 속성을 보장하는 책임은 어디에 있습니까?

** 내 질문은 특히 문구에 관한 것입니다.

는 ** 거래

에 의해 보장. 내 경험에 따라 이러한 속성은 트랜잭션에 의해 자동으로 처리되지 않습니다. 그러나 자바 개발자로서 우리는 이러한 속성 기준이 충족되는지 확인해야합니다.

는의 각 속성을 통해 가자 : -

  1. 자성 : - 우리는 계정이 강제 너무로 작성해야 고객을 만들 때 가정합니다. 이제 거래 도중 계정 생성 중에 고객이 생성되면 예외가 발생합니다. 이제 개발자는 완료 트랜잭션 (이 경우 원 자성이 충족 됨)을 롤백하거나 트랜잭션을 커밋하여 고객이 생성되지만 계정 (원 자성을 위반 함)이 생성되지 않도록 두 가지 방법을 사용할 수 있습니다. 따라서 책임은 개발자에게 있습니다.

  2. 일관성 : - 동일한 이유는 일관성을 위해 너무

  3. 절연을 유효 원하는 분야 - 정의 격리 트랜잭션이 다른 프로세스 또는 거래의 간섭없이 실행할 수에 따라.
    그러나 격리 수준을 Serializable으로 설정하면이 작업을 수행 할 수 있습니다. 다른 경우에는 커밋 된 읽기 또는 커밋되지 않은 읽기와 같은 경우에 변경 사항이 다른 트랜잭션에 표시됩니다. 따라서 개발자는 Serializable을 사용하여 정말로 분리 된 책임을 져야합니까?

  4. 내구성 : - 트랜잭션을 커밋하면 응용 프로그램이 충돌하더라도 응용 프로그램을 다시 시작할 때 커밋해야합니다. 개발자 나 데이터베이스 공급 업체/거래가주의를 기울여야하는지 확신 할 수 없습니까?

내 이해에 따라 이러한 ACID 속성은 자동으로 보장되지 않습니다. 오히려 우리는 개발자로서 그들을 성취 할 수 있습니다. 위의 각 사항에 대한 이해가 정확하다면 알려주세요. 당신이 사람들이 각 포인트에 대한 답장을 할 수있는 경우 예/아니오도 할 것 (감사하지 않을 것이다. 너무 요구 사항에 따라 달라집니다하지만, 대부분의 응용 프로그램에서 가장 논리적 인 격리 수준이어야합니다 최선을 다하고 내 이해 읽기 당으로

을.

+0

거의 모든 대답은 거래가 전적으로 데이터베이스에 의해 구현된다고 가정합니다. 이것은 정확하지 않습니다. 트랜잭션은 많은 다른 소프트웨어 하부 구조 구성 요소 (중간급 응용 프로그램 서버, 트랜잭션 모니터, 메시징 시스템, 객체 요청 브로커 등)로 구현할 수있는 일반적인 개념입니다. – steve

+0

격리 수준은 매우 데이터베이스에 따라 다릅니다. 예를 들어 오라클은 커밋되지 않은 읽기 전용 레벨을 제공하지 않습니다. 어쨌든 커밋 된 읽기는 oracle의 기본 격리 수준입니다. – steve

+0

이 질문은 더 많은 상향 보수를받을 자격이 있습니다 – vigamage

답변

3

을 트랜잭션은 ACID를 어느 정도 보증합니다 :

1) 원자 성. 트랜잭션은 모든 변경이 이루어 졌는지 또는 변경되지 않았 음을 보장합니다. 그러나 트랜잭션의 시작과 끝을 수동으로 설정하고 커밋 또는 롤백을 수동으로 수행해야합니다. 사용하는 기술 (EJB ...)에 따라 트랜잭션은 컨테이너 관리되며 시작 및 끝을 작성중인 전체 "메소드"로 설정합니다. 호출 된 메소드가 새 트랜잭션 또는 기존 트랜잭션이 필요하면 구성으로 제어 할 수 있습니다. ...

2) 일관성. 원 자성으로 보장됩니다.

3) 절연. 응용 프로그램에 필요한 분리 수준을 정의해야합니다. 기본값은 데이터베이스, 컨테이너에 따라 정의됩니다 ... 가장 일반적인 것은 READ COMMITTED입니다. 논리 및 격리 수준에 따라 데드 록을 유발할 수 있으므로 로크에주의하십시오.

4) 내구성. 데이터베이스에 의해 전적으로 관리됩니다. 커밋이 오류없이 실행되면 거의 모든 데이터베이스가 변경 내구성을 보장하지만 일부 시나리오에서는 디스크에 쓰기가 나중에 메모리에 캐시되고 나중에 플러시되는 경우가 발생할 수 있습니다.

일반적으로 (commit, rollback)을 선언하여 코드의 스타와 엔드를 선언하는 컨테이너에 구성합니다.

3
  1. 데이터베이스 트랜잭션 원자 있습니다 : 그들은 하나 전체적으로 발생 또는 전혀. 그 자체로는 비즈니스 트랜잭션의 원 자성에 대해서는 아무 것도 말하지 않습니다. 비즈니스 트랜잭션을 데이터베이스 트랜잭션에 맵핑하는 다양한 전략이 있습니다. 가장 간단한 경우 비즈니스 트랜잭션은 하나의 데이터베이스 트랜잭션 (데이터베이스 트랜잭션을 롤백하여 비즈니스 트랜잭션이 중단되는 위치)에서 구현됩니다. 그런 다음 데이터베이스 트랜잭션의 원 자성은 비즈니스 트랜잭션의 원 자성을 의미합니다. 그러나 일단 비즈니스 트랜잭션이 여러 데이터베이스 트랜잭션에 걸쳐지면 일이 까다로워집니다 ...
  2. 위를 참조하십시오.
  3. 진술 내용이 정확합니다. 종종, 약한 보증은 정확성을 증명하기에 충분합니다.
  4. 데이터베이스 트랜잭션은 내구성이 있습니다 (하드웨어 오류가없는 경우). 트랜잭션이 커밋되면 다른 트랜잭션이 데이터를 변경할 때까지 그 결과가 지속됩니다. 그러나 데이터베이스 또는 데이터베이스와 호출 코드 간의 네트워크가 실패 할 경우 호출 코드가 트랜잭션이 완료되었는지 여부를 알 수 없습니다. 따라서

    트랜잭션을 커밋하면 응용 프로그램이 충돌하더라도 응용 프로그램을 다시 시작할 때 커밋해야합니다.

    이 잘못되었습니다. 트랜잭션이 커밋 된 경우 수행 할 작업이 없습니다.

요약하면 데이터베이스는 강력한 동작 보증을 제공합니다. 분명히 전체 응용 프로그램의 동작에 대해 보장 할 수는 없습니다.

+0

+1 비즈니스 거래와 데이터베이스 거래의 구분이 중요합니다. – APC

관련 문제