I believe I can fly

EJB 컨테이너와 트랜잭션
EJB 개발자들은 세션빈의 메소드 단위로 트랜잭션 레벨을 설정할 수 있다는 것을 알고 있다. 또한 컨테이너가 개발자가 설정한 트랜잭션의 레벨에 따라 메소드 내의 트랜잭션을 하나로 묶어준다는 것도 알고 있다.

EJB의 실행중 속성정보를 갖고 있는 XML 파일안을 조작함으로써 트랜잭션 관리가 필요한 메소드를 지정할 수 있고(기본값은 ALL이다), 레벨 또한 조작할 수 있다.
설정 레벨은 REQUIRED로 지정한다(트랜잭션을 관리할 필요가 없는 업무정의가 존재하는 경우는 없다고 봐도 좋다).

컨테이너는 이 두 가지 정보를 가지고 메소드 시작시점부터 완료시점까지 Exception이 발생하게 되면 레벨이 REQUIRED일 경우 Exception발생 전까지 수행했던 작업을 모두 롤백시킨다.

설정레벨을 하위로 조정하면 Exception을 던지되 롤백시키지는 않는 현상이 벌어진다. 그러므로 이 XML의 기본값을 고치는 경우는 없고, 고쳐서도 안된다. VisualCafe와 같이 자동으로 EJB의 XML을 생성시켜주는 툴에서부터 모두 이 옵션을 기본적으로 REQUIRED로 설정하고 있다.

이렇게 트랜잭션을 컨테이너가 메소드 단위로 관리하므로 개발자 입장에서는 명시적으로 트랜잭션을 ON/OFF 하는 기능을 구현할 필요 없이 일정부분 태스크가 줄어든 상태로 볼 수 있다.

하지만 메소드 내에서 Connection을 씀에 있어 언제 Connection을 얻어오고 반환해야 할 지, 또는 Connection 객체를 몇 개 선언해 생성시켜 쓸 것인지와 같은 고민들은 컨테이너의 기능과 별개로 전체 프로젝트에 일관성 있게 적용되어야 할 표준으로 정해져야 하며, 이는 설계자와 개발자의 몫이다.

Message-driven Bean의 라이프 사이클

      <1> 존재하지않는 상태  ---------------------------------> 준비상태
              [ new Instance() / setMessageDrivenContext() / ejbCreate() ]

   <2> 준비상태  ---------------------------------> 존재하지않는 상태
                        [ ejbRemove() ]

Entity Bean : 누가 관리하느냐에 따라 BMP와 CMP로 구분된다.

1)BMP(Bean Managed Persistence) : Bean이 Data 관리
- 개발자가 직접 JDBC를 이용해서 직접 Bean을 제작
- SQL을 이용 (사용이유 : 특정 데이터베이스에 종속적인 SQL문을 이용하거나 복잡한 SQL문 사용 가능)
ex) student

2) CMP(Container Managed Persistence) : Container가 Data 관리
- 개발자가 JDBC코드를 작성하지 않고, 배치 디스크립터의 테이블 관계 설정만으로 컨테이너가 객체를 데이터베이스로부터 읽거나 저장하는 기능
- SQL대신에 EJB-QL을 이용(사용이유 : 특정 데이터베이스에 종속되지 않는 SQL작성가능)
ex) Video