응용 프로그램 서버가 Stateless EJB를 풀링하는 이유는 무엇입니까?왜 Stateless EJB가 풀링됩니까?
invoking에 대한 응용 프로그램의 작업 부하를 제어하는 것이 유용하다는 것을 이해할 수 있습니다. 그러나 이는 서버를 호출자 클라이언트와 FAÇADE로만 EJB 풀링을 정당화합니다.
내부 EJB (노출되지 않고 비즈니스 로직을 수행하기 위해 내부적으로 호출되는 것)를 풀링하면 어떤 이점이 있습니까? (Spring처럼) 공유 된 단일 인스턴스를 사용하는 대신에.
적어도 하나의 단점에 대해 생각해 볼 수 있습니다. 사용 빈도가 높은 내부 EJB가 병목 현상을 일으킬 수 있습니다.
Stateless 세션 빈 EJB는 반드시 스레드로부터 안전 할 필요는 없습니다. 그들은 한 번에 둘 이상의 스레드와 공유 할 수없는 JMS 세션과 같은 자원을 보유 할 수 있습니다. 따라서 서버는 동일한 빈에 대한 여러 요청을 동시에 처리 할 수 있습니다 (JMS 자원도 풀링되지만, 예를 들어 그것을 사용하여).
스테이트리스 EJB가 풀링 된 이유를 알고 싶습니다. 그러나 나는 그들이 필요에 따라 창조되고 파괴되기보다는 왜 풀링되는지 알고 싶다. 비 관련 요청에 대해 인스턴스를 재사용 할 수 있다는 사실은 무 상태 빈의 구현을 상당히 복잡하게 만듭니다. 즉, 인스턴스 필드의 사용에 대해 엄청나게주의해야한다는 의미이며, 큰 이점도 없습니다.
특히 성능상의 이점은 없습니다. 나는 JBoss (6, IIRC)에서 stateless beans의 구현을 찔렀다. 메소드 호출을 처리 할 배관은 사용 될 때마다 처음부터 다시 작성됩니다. 즉, 유일한 성능 절약은 단일 오브젝트 생성이며, 이는 사소한 시간이어야합니다. 콩이 무거운 가중치의 자원을 얻고 호출 사이에서 그들을 유지하는 경우가 아닌지 알 수있는 유일한 상황입니다. 그러나이 경우 콩은 실제로 영광스럽고 심하게 관리되는 수영장으로 사용되고 있습니다. 올바른 솔루션은 리소스를 직접 풀링하는 것입니다.
이제 EJB는 오랜 시간 동안 사용되었습니다. 그들이 처음 나왔을 때, 객체 생성은 비용이 많이 들었고, 따라서 객체를 생성하는 것이 합리적입니다. 그러나 그 시절은 오래 전에 사라졌습니다. 왜 풀링은 EJB3에서 삭제되지 않았습니까?
글쎄요, 수천 개의 동시 요청이 있다면 메모리에 수천 개의 인스턴스가있는 대신 스레드 안전하다고 확신하는 한 @Singleton으로 풀링하는 것이 좋습니다. –
bean이 threadsafe라면, 그렇습니다. singleton이 이상적입니다. 그러나 그렇지 않은 경우 풀링 된 인스턴스와 스로 웨이 인스턴스의 메모리로드가 비슷합니다. 풀링 된 인스턴스는 실제로 보육원에서 탈출 할 수있을만큼 오래 살기 때문에 가비지 컬렉터에 * 더 많은 작업을 제공합니다. –
큰 주장입니다. 나는 그것이 각 요청을 처리하는 데 걸리는 시간과 그 객체가 풀에서 소비하는 시간에 달려 있다고 생각합니다. 대부분을 어느 시점에서든 사용할 수 있다면 생성/삭제에 약간의 이점을 얻을 수 있습니다. 이것은 또한 트래픽 경향 등에 따라 달라집니다. 이것은 IMO에서 너무 세밀한 분석입니다 :) –
상태 비 저장 상태이면 병행성에 의해 위협받을 상태가 존재하지 않으므로 경쟁 조건이 나타나지 않을 수 있습니다. 따라서 스레드로부터 안전합니다. 예, 저는 그들이 주입 된 자원과 같은 일부 주를 알고 있지만, 무국적자라고해서는 안됩니다. :) 나는 답을 올바른 것으로 생각한다. – edutesoy
@edutesoy 귀하의 설명에 동의합니다. 그러나 왜 국가가 유지되고 있는가? –