EJB 데이터 중개자 서비스 프로그래밍 고려사항

제품에서 제공된 EJB(Enterprise JavaBeans) DMS(Data Mediator Service)를 활용하여 애플리케이션 작성을 시작하면, 다음 항목을 고려하십시오.

EJB 프로그래밍 모델

EJB 프로그래밍 모델의 서브세트만이 EJB 데이터 중개자 서비스에서 지원됩니다.
  • EJB 콜렉션 매개변수를 사용하여 EJB 인스턴스에서 데이터를 검색하는 경우 또는 applyChanges를 사용하여 EJB 인스턴스를 사용하는 경우:
    • EJB DMS는 엔터프라이즈 Bean에 대한 로컬 인터페이스를 사용합니다. CMP(Container-Managed Persistence) 필드에 대한 Gettersetter 호출은 조회 표현식에서 사용된 EJB 메소드뿐만 아니라 로컬 인터페이스로 승격되어야 합니다.
    • EJB를 작성하는 중개자의 경우, EJB 홈에서 정의된 인수 메소드만으로 기본 키 클래스를 사용하는 작성 메소드가 있어야 합니다. 이러한 메소드가 존재하지 않으면, 작성 조작을 처리하는 어댑터를 제공해야 합니다. 또한 EJB에 정의된 EJBLocalHome 인터페이스는 다음 메소드를 포함해야 합니다(작성 메소드 외에).
      findByPrimaryKey(<key class>)
      remove (java.lang.Object)
      create (<key class>)
  • 데이터베이스에 대한 applyChanges 메소드 직접 호출 시, 다음이 발생합니다.
    • 무시 컨테이너가 업데이트됩니다. 적절한 컨테이너 캐시 옵션 사용 및 트랜잭션 종료 시 가능한 빨리 새로 고치기를 강제 실행해야 합니다.
    • EJB CMR(Container-Managed Relationship) 유지보수를 무시합니다. DataGraph로 검색되지 않는 이 관계를 유지보수하려면 데이터베이스 RI를 사용해야 합니다.
  • CMP 필드는 허용된 유형이어야 합니다. 이 유형의 목록은 EJB 중개자 조회 구문의 내용을 참조하십시오.
  • EJB 변환기/작성자를 사용하는 사용자 정의 유형의 CMP 필드가 지원되지 않습니다.

다음 테이블은 EJB DMS에서 지원되지 않는 EJB 프로그래밍 모델의 제한사항을 표시합니다.

표 1. EJB DMS를 사용한 EJB 프로그래밍 모델 제한사항. 다음 테이블은 EJB DMS에서 지원되지 않는 EJB 프로그래밍 모델의 제한사항을 표시합니다.
  db에서 직접 검색 EJB 컨테이너에서 검색 db에 직접 업데이트 EJB를 통해 업데이트
EJB persistence inheritance 아니오 아니오 아니오 아니오
EJB cmp field with converter 아니오 아니오

트랜잭션

  • 작성을 포함한 모든 중개자 호출은 사용자 트랜잭션이나 컨테이너 트랜잭션의 트랜잭션 범위 내에 수행되어야 합니다. create, getGraph 및 applyChanges를 포함한 여러 중개자 호출은 동일한 트랜잭션 내에서 호출되지 않아도 됩니다. 사실 대부분의 호출은 별도의 트랜잭션에서 자주 수행됩니다.

액세스 인텐트

  • 중개자 조회가 ASN(Abstract Schema Name)을 사용하여 EJB를 참조하면, 데이터는 데이터베이스에서 직접 검색됩니다. 데이터 소스 연결 시 사용된 액세스 인텐트 및 격리 레벨은 EJB 동적 조회 액세스 인텐트에 대한 애플리케이션 프로파일에 지정된 액세스 인텐트입니다. DataGraph는 연결이 끊긴 프로그래밍 모델에서 사용될 계획이기 때문에 애플리케이션에 대해 낙관적인 액세스 인텐트를 정의하는 것이 좋습니다.
  • 중개자가 EJB 콜렉션을 사용하여 데이터를 검색하면, 애플리케이션 프로파일에서 지정된 액세스 인텐트는 EJB가 활성화를 필요로 하는 경우 사용됩니다.
  • applyChanges 중, 낙관적인 동시성 제어가 사용되어 데이터베이스에 변경사항을 적용하기 전에 DataObject에서 특정 필드를 확인합니다. 업데이트는 기본적으로 검색의 다른 트랜잭션에서 처리됩니다. 그러므로, 업데이트가 유실되지 않도록 다른 트랜잭션이 데이터를 업데이트하지 않았는지 확인해야 합니다. EJB의 RDB로의 맵핑 정의 시, 하나 이상의 EJB 필드를 낙관적 술어로 지정할 수 있습니다. 현재 데이터베이스 값을 DataGraph 변경 로그의 이전 값과 비교한 확인에 필드가 사용됩니다. 검증이 성공하면 필드의 현재 값이 데이터베이스에 기록됩니다. 비교가 false를 리턴하고 업데이트가 실패하면 예외가 발생합니다. 다음 예와 같이 추가 술어가 추가된 단일 업데이트 명령문으로 이 모두가 수행됩니다. optimisticPredicate 필드는 myColumn1입니다.
      update  myTable set  myColumn1="new value1", myColumn2="new value2"where myKey="key value" and myColumn1="old value1"
  • applyChanges가 EJB 컨테이너를 통해 수행되면, 엔터프라이즈 Bean의 현재 값은 낙관적 술어 필드의 이전 값과 비교됩니다. 값이 일치하지 않으면 예외가 발생합니다.
  • 하나 이상의 EJB 필드를 optimisticPredicates로 정의한 다음 SDO가 업데이트 가능하면, 하나 이상의 optmisticPredicate 필드는 데이터 오브젝트로 검색되어야 합니다. 그렇지 않은 경우, applyChanges는 예외를 리턴합니다. 필드는 호출자나 데이터베이스 트리거에 의해 업데이트되어야 하며, 중개자는 자동으로 필드를 증분하거나 설정하지 않습니다.
  • 모든 필드가 검증되는 것은 아니며 이 필드만 EJB-RDB 맵핑에서 optimisticPredicate로 표시됩니다.
  • EJB 맵핑 도구를 사용하면 optimisticPredicate 필드가 없을 수 있습니다. 이 경우 중개자는 검증 없이 업데이트를 수행합니다.
  • 작성 및 삭제 조작은 낙관적 술어 필드를 사용하지 않습니다.
  • EJB 인스턴스를 통해 변경사항을 적용하면, EJB가 먼저 활성화되어야 할 수 있습니다. 이 경우 EJB 메소드와 연관된 해당 액세스 인텐트가 적용됩니다. 비관적 액세스 인텐트가 있는 프로파일에서 applyChanges를 실행하는 것이 좋으며, 그렇지 않은 경우 낙관적 동시성 로직이 두 번 호출됩니다. 한 번은 데이터 오브젝트 값을 EJB로 복사할 때이고 두 번째는 지속성 관리자가 데이터베이스 레코드에 대해 EJB 필드 값의 이전 값을 비교할 때입니다.
  • 데이터베이스에서 직접 검색할 때 중개자에서 사용된 액세스 인텐트는 첫 번째 조회 명령문에서 이름 지정된 EJB에 정의된 기본 액세스 인텐트입니다.

우수 사례

  • getGraph를 하나의 중개자 인스턴스에서 호출하고, 리턴된 DataGraph를 업데이트한 다음 다른 중개자 인스턴스에서 applyChanges를 호출할 수 있습니다. 그러나 동일 중개자 인스턴스가 필요하지 않지만 동일한 query shape가 필요합니다. 조회 쉐이프는 조회 명령문의 수와 순서, SELECT 및 FROM 절에서 지정된 필드와 관계 등입니다.
  • 가능한 경우 createMediator에 대한 반복된 호출을 피하십시오. 매개변수화된 조회를 사용하고 getGraph를 사용하여 다른 매개변수 값으로 전달합니다.

주제 유형을 표시하는 아이콘 참조 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rejb_ejbmedpcon
파일 이름:rejb_ejbmedpcon.html