JSF는 언제까지 서버 측에서 UI 구성 요소의 상태를 저장하고 UI 구성 요소의 상태 정보 가 서버 메모리에서 정확히 제거 되는시기는 언제입니까? 애플리케이션에 로그인 한 사용자가 페이지를 탐색 할 때 구성 요소의 상태가 서버에 계속 누적됩니까?
UI 구성 요소 상태를 서버에 유지하는 이점이 무엇인지 이해하지 못합니다 !? 검증 된 / 변환 된 데이터를 관리 Bean에 직접 전달하지 않습니까? 나는 그것을 피할 수 있습니까?
수천 개의 동시 사용자 세션이있는 경우 서버 측에서 너무 많은 메모리 를 소비하지 않습니까? 사용자가 특정 주제에 대한 블로그를 게시 할 수있는 애플리케이션이 있습니다. 이 블로그는 크기가 상당히 큽니다. 포스트 백이나 블로그보기 요청 이있을 때이 큰 페이지 데이터가 구성 요소 상태의 일부로 저장됩니까? 이것은 너무 많은 메모리를 소모합니다. 이것이 문제가되지 않습니까?

업데이트 1 :

이제 더 이상 JSF를 사용하는 동안 상태를 저장할 필요가 없습니다. 고성능 Stateless JSF 구현을 사용할 수 있습니다. 관련 세부 사항 및 토론 은이 블로그 및 이 질문 을 참조하십시오 . 또한 JSF에 대한 상태 비 저장 모드를 제공하는 옵션 인 JSF 사양에 포함해야 할 미해결 문제 가 있습니다. (PS는 문제에 대한 투표를 고려 ,이 & 이 이 당신을 위해 유용한 기능입니다 경우.)

업데이트 2 (2013 년 2 월 24 일) :

Mojarra 2.1.19 가 stateless 모드 로 나왔다는 좋은 소식입니다 !

여기를 보아라:

http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255

http://java.net/jira/browse/JAVASERVERFACES-2731

http://balusc.blogspot.de/2013/02/stateless-jsf.html

답변

JSF가 서버 측에 UI 구성 요소의 상태를 저장해야하는 이유는 무엇입니까?

HTTP는 상태 비 저장이고 JSF는 상태 저장이기 때문입니다. JSF 구성 요소 트리는 동적 (프로그래밍 방식) 변경의 대상이됩니다. JSF는 양식이 최종 사용자에게 표시되었을 때의 정확한 상태를 알면됩니다. 그러면 양식이 다시 제출 될 때 원래 JSF 구성 요소 트리에서 제공 한 정보를 기반으로 전체 JSF 라이프 사이클을 성공적으로 처리 할 수 있습니다. 서버. 컴포넌트 트리는 요청 매개 변수 이름, 필요한 변환기 / 유효성 검사기, 바인딩 된 관리 Bean 특성 및 조치 메소드에 대한 정보를 제공합니다.

JSF는 언제까지 서버 측에서 UI 구성 요소의 상태를 저장하며 UI 구성 요소의 상태 정보는 정확히 언제 서버 메모리에서 제거됩니까?

이 두 가지 질문은 똑같이 요약되는 것 같습니다. 어쨌든 이것은 구현에 따라 다르며 상태가 서버 또는 클라이언트에 저장되는지 여부에 따라 다릅니다. 약간 괜찮은 구현은 만료되었거나 대기열이 가득 차면 제거합니다. 예를 들어 Mojarra는 상태 저장이 세션으로 설정된 경우 기본 제한이 15 개의 논리적 뷰입니다. 다음 컨텍스트 매개 변수를 사용하여 구성 할 수 있습니다 web.xml.

<context-param>
    <param-name>com.sun.faces.numberOfLogicalViews</param-name>
    <param-value>15</param-value>
</context-param>

다른 Mojarra 관련 매개 변수 및 관련 답변 com.sun.faces.numberOfViewsInSession 대 com.sun.faces.numberOfLogicalViews 는 Mojarra FAQ 를 참조하십시오.

애플리케이션에 로그인 한 사용자가 페이지를 탐색 할 때 구성 요소의 상태가 서버에 계속 누적됩니까?

기술적으로는 구현에 따라 다릅니다. 페이지 간 탐색 (GET 요청)에 대해 이야기하는 경우 Mojarra는 세션에 아무것도 저장하지 않습니다. 그러나 POST 요청 (명령 링크 / 버튼이있는 양식) 인 경우 Mojarra는 최대 제한까지 세션에서 각 양식의 상태를 저장합니다. 이를 통해 최종 사용자는 동일한 세션의 다른 브라우저 탭에서 여러 양식을 열 수 있습니다.

또는 상태 저장이 클라이언트로 설정되면 JSF는 세션에 아무것도 저장하지 않습니다. 다음 컨텍스트 매개 변수를 사용하여 수행 할 수 있습니다 web.xml.

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>

그런 다음 javax.faces.ViewState양식 이름 이 있는 숨겨진 입력 필드의 암호화 된 문자열로 직렬화됩니다 .

나는 서버 측에서 UI 구성 요소의 상태를 유지하는 이점이 무엇인지 이해하지 못합니다. 검증 된 / 변환 된 데이터를 관리 Bean에 직접 전달하지 않습니까? 그것을 피할 수 / 피해야합니까?

JSF의 무결성과 견고성을 보장하기에는 충분하지 않습니다. JSF는 제어의 단일 진입 점이있는 동적 프레임 워크입니다. 상태 관리하지 않고, 하나의 수 스푸핑 / 해킹 HTTP 어떤 방법으로 요청 (예를 들어, 조작 것 disabled, readonly및 rendered특성), JSF는 다른 – 그리고 잠재적으로 hazardful- 일을 할 수 있도록. CSRF 공격과 피싱에 취약합니다.

수천 개의 동시 사용자 세션이있는 경우 서버 측에서 너무 많은 메모리를 소비하지 않을까요? 사용자가 특정 주제에 대한 블로그를 게시 할 수있는 애플리케이션이 있습니다. 이 블로그는 크기가 상당히 큽니다. 포스트 백 또는 블로그보기 요청이있을 때 큰 블로그는 구성 요소 상태의 일부로 저장됩니다. 이것은 너무 많은 메모리를 소비합니다. 이것이 문제가되지 않습니까?

메모리는 특히 저렴합니다. 앱 서버에 충분한 메모리를 제공하십시오. 또는 네트워크 대역폭이 더 저렴한 경우 상태 저장을 클라이언트 측으로 전환하십시오. 최적의 일치를 찾으려면 예상되는 최대 동시 사용자 수로 웹앱을 스트레스 테스트하고 프로파일 링 한 다음 앱 서버에 측정 된 최대 메모리의 125 % ~ 150 %를 제공하십시오.

JSF 2.0은 상태 관리에서 많이 향상되었습니다. 그것은 (예 : 부분적인 상태를 저장하는 것이 가능 단지 (가) <h:form>대신에 전체 물건의 저장됩니다 <html>모든 끝으로가는 길). 예를 들어 Mojarra는 그렇게합니다. 10 개의 입력 필드 (각각 레이블 및 메시지 포함)와 2 개의 버튼이있는 평균 양식은 1KB를 넘지 않습니다. 세션에 15 개의 뷰가있는 경우 세션 당 15KB를 넘지 않아야합니다. 최대 1000 명의 동시 사용자 세션이있는 경우 15MB를 넘지 않아야합니다.

세션 또는 애플리케이션 범위에있는 실제 개체 (관리 Bean 및 / 또는 DB 엔터티)에 더 중점을 두어야합니다. 필자는 레코드를 필터링 / 그룹화 / 정렬하기 위해 SQL 대신 Java가 사용 된 세션 범위 빈의 풍미에서 전체 데이터베이스 테이블을 Java의 메모리로 불필요하게 복제하는 많은 코드와 프로젝트를 보았습니다. ~ 1000 개의 레코드를 사용하면 사용자 세션 당 10MB를 쉽게 초과 할 수 있습니다 .