ping 테스트와 같은 네트워크 노드에서 몇 가지 테스트를 수행하는 응용 프로그램에서 디스크 공간을 검색 할 수 있습니다.Batchlet 대 EJB 타이머
나는 작업을 실행하기 위해 예정된 배치를 사용하지만 배치 배치의 엄밀한 사용인지 궁금합니다.
EJB 타이머가 더 관련이 있어야합니까? 또한 batchlet을 실행할 때 글래스 피쉬 서버는 일괄 처리 로그를 유지하므로 필요하지 않습니다 (특히 하루 동안 생성되는 일괄 처리 작업의 양과 함께).
같은 일정 시간에 일부 작업을 실행해야한다면 일괄 적으로 처리 할 수 있지만 EJB 타이머도 사용할 수 있다고 생각하십니까?
혹시 궁금한 점이 있으시면 알려주십시오. 당신의 작업은 눈 깜짝 할 (또는 그 부근)에서 실행 할 때 EJB 타이머를 사용
덕분에, Ersch
분명히 대답할만한 질문은 아니지만 일괄 처리 작업으로 응용 프로그램을 분해하는 데 약간의 비용이 들며, 그렇게할만한 가치가 있는지 알고 싶습니다.
단일 배치 단계로 구성된 작업에 대해 생각하고 있습니다. 음, "재시작"기능으로 얻은 결과는 없으며, 작업 내에서 실패한 단계에서도 청크 단계에서 체크 포인트를 활용할 수도 없습니다. 배치 렛 프로그래밍 모델은 매우 간단합니다. @BatchProperty를 정말 좋아한다고해도 XML을 처리해야합니다.
나머지 일괄 처리 작업과 함께 이러한 실행을 시작, 확인 및 관리하려는 경우에만 더 흥미로운 일이 시작됩니다. 이는 특정 종류의 구현 특정 애드온 기능을 제공하는 구현으로 작업하고 있기 때문일 수 있습니다. 예를 들어 외부 스케줄러 소프트웨어와 통합하여 작업을 스케줄링 할 수 있습니다. 다른 극단적 인 경우, 모든 일괄 처리 작업 실행의 지속 기록을 한 곳 (작업 리포지토리, 일반적으로 영구 DB)에 저장하는 것이 가치 있다고 생각하면 가치있는 작업이 될 수 있습니다.
하지만 아무 것도 신경 쓰지 않는다면 EJB 타이머가 대신 사용할 수 있습니다.
적합합니다.
그렇지 않으면 일괄 처리 메커니즘을 사용하십시오.
EJB 타이머에서 실행되는 장기 실행 태스크는 일반적으로 단기간 후에 시간 초과되는 트랜잭션에서 실행되기 때문에 문제가 될 수 있습니다. 이 트랜잭션 시간을 늘리면 데이터베이스 및 응용 프로그램의 정상 작동에 영향을 줄 수있는 다른 리소스 잠금 가능성이 높아집니다.
트랜잭션 내에서 타이머 태스크를 실행할 필요는 없습니다. –
작업이 제대로 완료되면 유효성 검사 또는 확인이 필요하지 않습니다. 내가하고 싶은 것은 노드가 살아 있는지 확인하고 살아 있지 않다면 애플리케이션에 경고를 생성하는 것입니다. 디스크 공간 검사의 경우 여유 공간 트리거에 도달하면 경고를 작성하십시오. EJB에서 기능 구현을했지만 테스트가 실행되는 동안 성능 문제가있었습니다. 배경에서 배설물을 찾은 이유가 여기에 있습니다. "공부 끝"작업이므로 가능한 한 많은 코드를 작성해야하며, 필자의 필요를 파악하는 데 도움이되기를 바랍니다. – Ersch
배치 표가 타이머에 부딪히는 성능 문제를 피할 수있는 이유는 분명하지 않습니다. 글쎄, 행운을 빈다. –
아마 내가 EJB를 잘못 사용했기 때문에 직접 jsf 페이지를 렌더링하기 위해 노드 상태를 검사하는 메소드를 호출하여 내 페이지가 고정 된 메소드를 실행하는 중일 수 있습니다. 또한, 시간에 실행하는 일부 배치를 가질 수 있지만 우리가 EJB 타이머를 통해 할 수 있는지 궁금해. – Ersch