JSF가 UI 컴포넌트 상태를 서버에 저장하는 이유는 무엇입니까?
JSF는 어느 시점까지 서버 측의 UI 컴포넌트 상태를 저장합니까?또한 UI 컴포넌트의 상태 정보는 서버 메모리에서 정확히 언제 삭제됩니까?로그인한 사용자가 페이지를 탐색할 때 컴포넌트 상태가 서버에 계속 축적됩니까?
서버에서 UI 컴포넌트 상태를 유지하면 어떤 이점이 있는지 모르겠습니다!?검증/변환된 데이터를 관리 대상 콩에 직접 전달하면 충분하지 않습니까?피할 수 있을까요, 아니면 피할까요?
동시 사용자 세션이 수천 개일 경우 서버 측에서 메모리를 너무 많이 사용하지 않습니까?사용자가 특정 주제에 대한 블로그를 게시할 수 있는 앱이 있습니다.이 블로그는 규모가 꽤 큽니다.블로그 열람에 대한 포스트백이나 요청이 있을 때 이 큰 페이지 데이터는 컴포넌트 상태의 일부로 저장됩니까?이렇게 하면 메모리가 너무 많이 소모됩니다.이거 걱정되는 거 아니야?
업데이트 1:
이제 JSF를 사용하는 동안 상태를 저장할 필요가 없습니다.고성능 상태 비저장 JSF 구현을 사용할 수 있습니다.자세한 내용은 이 블로그와 이 질문을 참조해 주세요.또, JSF 의 스테이트리스 모드를 제공하는 옵션인 JSF 사양에 포함시키는 미해결의 문제도 있습니다.(P.S. 이것이 도움이 되는 기능이라면, 이 문제에 투표해 주세요.)
업데이트 2(2013년 2월 24일):
Mojarra 2.1.19가 스테이트리스 모드로 출시되었다는 희소식!
여기를 참조해 주세요.
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 라이프사이클을 성공적으로 처리할 수 있습니다.구성 요소 트리는 요청 매개 변수 이름, 필요한 변환기/검증기, 바인딩된 관리 빈 속성 및 작업 메서드에 대한 정보를 제공합니다.
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.numberOfViews에 대해서는 Mojarra FAQ도 참조하십시오.InSession vs com.sun.faces.numberOfLogicalViews
로그인한 사용자가 페이지를 탐색할 때 컴포넌트 상태가 서버에 계속 축적됩니까?
엄밀히 말하면, 그것은 실장에 의해서 다릅니다.페이지 투 페이지 내비게이션(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 컴포넌트 상태를 유지하는 것의 이점을 이해할 수 없습니다.검증/변환된 데이터를 관리 대상 콩에 직접 전달하면 충분하지 않습니까?피하려고 해도 될까요?
이는 JSF의 무결성과 견고성을 보장하는 데 충분하지 않습니다. JSF는 단일 진입 제어 지점이 있는 동적 프레임워크입니다.매니지먼트가 , 스푸핑를 들면, 「Manipleding」HTTP 「Manipleding」)를 할 수 ( 「Manipleding」HTTP 「」( 「Maniping 「HTTP」)/「Maniping」( 「Maniping 「HTTP」)).disabled,readonly ★★★★★★★★★★★★★★★★★」rendered속성) JSF가 여러 가지(잠재적으로 위험한) 일을 하도록 한다.CSRF에 의한 것입니다.
또한 동시 사용자 세션이 수천 개일 경우 서버 측에서 메모리가 너무 많이 소모되지 않습니까?사용자가 특정 주제에 대한 블로그를 게시할 수 있는 앱이 있습니다.이 블로그는 규모가 꽤 큽니다.포스트백이나 블로그 열람 요청이 있을 경우 큰 블로그는 컴포넌트 상태의 일부로 저장됩니다.이렇게 하면 메모리가 너무 많이 소모됩니다.이거 걱정되는 거 아니야?
메모리는 특히 싸다.appserver에 충분한 메모리만 주면 됩니다.또는 네트워크 대역폭이 더 저렴한 경우 클라이언트 측으로 상태 저장을 전환하기만 하면 됩니다.최적의 일치를 찾으려면 웹 어플리케이션의 최대 동시 사용자 수를 예측하여 프로파일링한 다음 측정된 최대 메모리의 125%~150%를 앱서버에 제공합니다.
JSF 2.0은 상태 관리 기능이 크게 향상되었습니다.부분 상태를 저장할 수 있습니다(예:<h:form>모든 것이 아니라 보존될 것이다<html>끝까지).예를 들어 Mojarra는 그렇게 한다.10개의 입력 필드(각각 라벨과 메시지 포함)와 2개의 버튼이 있는 평균 폼은 1KB를 넘지 않습니다.세션에 15개의 뷰가 있는 경우 세션당 15KB를 초과할 수 없습니다.최대 1000개의 동시 사용자 세션에서는 15MB를 초과할 수 없습니다.
세션 또는 애플리케이션 범위의 실제 객체(관리 대상 콩 및/또는 DB 엔티티)에 더 집중해야 합니다.레코드 필터링/그룹화/배열을 위해 SQL 대신 Java가 사용되는 세션 스코프 빈의 맛으로 데이터베이스 테이블 전체를 Java 메모리에 불필요하게 복제하는 코드와 프로젝트를 많이 봐왔습니다.최대 1000개의 레코드로 사용자 세션당 10MB를 쉽게 초과할 수 있습니다.
언급URL : https://stackoverflow.com/questions/5474316/why-jsf-saves-the-state-of-ui-components-on-server
'itsource' 카테고리의 다른 글
| MariaDB 5.3에서 5.5로의 업그레이드 (0) | 2022.09.19 |
|---|---|
| JavaScript 양식 제출 - 제출 확인 또는 취소 대화 상자 (0) | 2022.09.19 |
| Java에서 숫자에 선행 0을 추가하시겠습니까? (0) | 2022.09.19 |
| PHP에서 문자열을 JSON 개체로 변환하는 방법 (0) | 2022.09.19 |
| PDO::_construct(): 서버가 클라이언트에 알 수 없는 문자 집합(255)을 보냈습니다.개발자에게 보고해 주세요. (0) | 2022.09.18 |