|
Hibernate example source code file (performance.po)
This example Hibernate source code file (performance.po) is included in the DevDaily.com
"Java Source Code
Warehouse" project. The intent of this project is to help you "Learn Java by Example" TM.
The Hibernate performance.po source code
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2010-02-04T04:51:22\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#. Tag: title
#, no-c-format
msgid "Improving performance"
msgstr "퍼포먼스 개선하기"
#. Tag: title
#, no-c-format
msgid "Fetching strategies"
msgstr "페칭 방도들"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate uses a <emphasis>fetching strategy to retrieve "
"associated objects if the application needs to navigate the association. "
"Fetch strategies can be declared in the O/R mapping metadata, or over-ridden "
"by a particular HQL or <literal>Criteria query."
msgstr ""
"<emphasis>페칭 방도는 어플리케이션이 연관을 네비게이트할 필요가 있"
"을 때 Hibernate가 연관된 객체들을 검색하는데 사용하게 될 방도이다.페치 방도들"
"은 O/R 매핑 메타데이터 내에서 선언될 수 있거나 하나의 특정 HQL 또는 "
"<literal>Criteria 질의에 의해 오버라이드 될 수도 있다."
#. Tag: para
#, no-c-format
msgid "Hibernate3 defines the following fetching strategies:"
msgstr "Hibernate3는 다음 페칭 방도들을 정의한다:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Join fetching: Hibernate retrieves the associated "
"instance or collection in the same <literal>SELECT, using an "
"<literal>OUTER JOIN."
msgstr ""
"<emphasis>Join 페칭 - Hibernate는 OUTER JOIN을 "
"사용하여 연관된 인스턴스 또는 동일한 <literal>SELECT 내에서 콜렉션"
"을 검색한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Select fetching: a second SELECT is "
"used to retrieve the associated entity or collection. Unless you explicitly "
"disable lazy fetching by specifying <literal>lazy=\"false\", this "
"second select will only be executed when you access the association."
msgstr ""
"<emphasis>Select 페칭 - 두 번째 SELECT는 연과"
"된 엔티티 또는 콜렉션을 검색하는데 사용된다. 당신이 <literal>lazy=\"false\""
"literal>를 지정함으로써 명시적으로 lazy 페칭을 사용 불가능하게 하지 않는 한, "
"이 두 번째 select는 당신이 그 연관에 실제로 액세스할 때 오직 실행될 것이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Subselect fetching: a second SELECT "
"is used to retrieve the associated collections for all entities retrieved in "
"a previous query or fetch. Unless you explicitly disable lazy fetching by "
"specifying <literal>lazy=\"false\", this second select will only "
"be executed when you access the association."
msgstr ""
"<emphasis>Subselect 페칭 - 두 번째 SELECT는 이"
"전 질의 또는 페치에서 검색된 모든 엔티티들에 대해 연관된 콜렉션들을 검색하는"
"데 사용된다. 당신이 <literal>lazy=\"false\"를 지정하여 명시적으로 "
"lazy 페칭을 사용 불가능하게 하지 않는 한, 이 두 번째 select는 당신이 실제로 "
"그 연관에 접근할 때 오직 실행될 것이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Batch fetching: an optimization strategy for select "
"fetching. Hibernate retrieves a batch of entity instances or collections in "
"a single <literal>SELECT by specifying a list of primary or "
"foreign keys."
msgstr ""
"<emphasis>Batch 페칭 - select 페칭을 위한 최적화 방도 - Hibernate"
"는 프라이머리 키들이나 foreign 키들의 리스트를 지정함으로써 하나의"
"<literal>SELECT 내에서 엔티티 인스턴스들이나 콜렉션들에 대한 batch"
"를 검색한다."
#. Tag: para
#, no-c-format
msgid "Hibernate also distinguishes between:"
msgstr "Hibernate는 또한 다음 사이를 구별 짓는다:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Immediate fetching: an association, collection or "
"attribute is fetched immediately when the owner is loaded."
msgstr ""
"<emphasis>즉각적인 페칭 - 소유자가 로드될 때, 연관, 콜렉션 또는 속"
"성이 즉시 페치된다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Lazy collection fetching: a collection is fetched when "
"the application invokes an operation upon that collection. This is the "
"default for collections."
msgstr ""
"<emphasis>Lazy 콜렉션 페칭 - 어플리케이션이 그 콜렉션에 대해 하나"
"의 오퍼레이션을 호출할 때 콜렉션이 페치된다.(이것은 콜렉션들에 대해 디폴트이"
"다.)"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>\"Extra-lazy\" collection fetching: individual elements "
"of the collection are accessed from the database as needed. Hibernate tries "
"not to fetch the whole collection into memory unless absolutely needed. It "
"is suitable for large collections."
msgstr ""
"<emphasis>\"Extra-lazy\" 콜렉션 페칭 - 콜렉션의 개별 요소들은 필요"
"할 때 데이터베이스로부터 접근된다. Hibernate는 절대적으로 필요하지 않은 한 전"
"체 콜렉션을 메모리 내로 페치하려고 시도하지 않는다(매우 큰 콜렉션에 적합함)"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Proxy fetching: a single-valued association is fetched "
"when a method other than the identifier getter is invoked upon the "
"associated object."
msgstr ""
"<emphasis>프락시 페칭 - 식별자 getter가 아닌 다른 메소드가 연관된 "
"객체에 대해 호출될 때 단일 값 연관이 페치된다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>\"No-proxy\" fetching: a single-valued association is "
"fetched when the instance variable is accessed. Compared to proxy fetching, "
"this approach is less lazy; the association is fetched even when only the "
"identifier is accessed. It is also more transparent, since no proxy is "
"visible to the application. This approach requires buildtime bytecode "
"instrumentation and is rarely necessary."
msgstr ""
"<emphasis>\"No-proxy\" 페칭 - 인스턴스 변수가 접근될 때 단일 값 연"
"관이 페치된다. 프락시 페칭과 비교할 때, 이 접근법은 다소 덜 lazy하지만(그 연"
"관은 심지어 유일하게 식별자가 접근될 때에도 페치된다)보다 투명하다. 왜냐하면 "
"프락시는 어플리케이션에 가시적이지 않기 때문이다. 이 접근법은 빌드 시 바이트"
"코드 수단을 필요로 하며 드물게 필요하다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Lazy attribute fetching: an attribute or single valued "
"association is fetched when the instance variable is accessed. This approach "
"requires buildtime bytecode instrumentation and is rarely necessary."
msgstr ""
"<emphasis>Lazy 속성 페칭 - 인스턴스 변수가 접근될 때 속성 또는 단"
"일 값 연관이 페치된다 이 접근법은 빌드시 바이트코드 수단을 필요로 하며 드물"
"게 필요하다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"We have two orthogonal notions here: <emphasis>when is the "
"association fetched and <emphasis>how is it fetched. It is "
"important that you do not confuse them. We use <literal>fetch to "
"tune performance. We can use <literal>lazy to define a contract "
"for what data is always available in any detached instance of a particular "
"class."
msgstr ""
"우리는 여기서 두 개의 직교하는 개념들을 갖는다: 연관이 페치될 <emphasis>때"
"emphasis>, 그리고 그것이 페치되는 <emphasis>방법(사용되는 SQL). 그"
"것들을 혼동하지 말라! 우리는 퍼포먼스를 튜팅하는데 <literal>페치를 "
"사용한다. 우리는 특정 클래스의 어떤 detached 인스턴스 내에서 항상 이용 가능"
"한 데이터가 무엇인지에 대한 계약을 정의하는데 <literal>lazy를 사용"
"할 수 있다."
#. Tag: title
#, no-c-format
msgid "Working with lazy associations"
msgstr "lazy 연관들로 작업하기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"By default, Hibernate3 uses lazy select fetching for collections and lazy "
"proxy fetching for single-valued associations. These defaults make sense for "
"most associations in the majority of applications."
msgstr ""
"디폴트로 Hibernate3는 콜렉션들에 대해 lazy select 페칭을 사용하고, 단일 값 연"
"관들에 대해 lazy 프락시 페칭을 사용한다. 이들 디폴트들은 거의 모든 어플리케이"
"션들에서 거의 모든 연관들에 대해 유의미하다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If you set <literal>hibernate.default_batch_fetch_size, Hibernate "
"will use the batch fetch optimization for lazy fetching. This optimization "
"can also be enabled at a more granular level."
msgstr ""
"<emphasis>노트: 만일 당신이 hibernate."
"default_batch_fetch_size</literal>를 설정하는 경우, Hibernate는 lazy 페칭을 "
"위한 batch 페치 최적화를 사용할 것이다(이 최적화는 또한 더 많은 과립상의 레벨"
"에서 이용 가능할 수 있다)."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Please be aware that access to a lazy association outside of the context of "
"an open Hibernate session will result in an exception. For example:"
msgstr ""
"하지만, lazy 페칭은 당신이 알고 있어야 하는 한 가지 문제를 제기한다. 열려진 "
"Hibernate 세션 컨텍스트 외부에서 lazy 연관에 대한 접근은 예외상황으로 귀결될 "
"것이다. 예를 들면 :"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Since the permissions collection was not initialized when the "
"<literal>Session was closed, the collection will not be able to "
"load its state. <emphasis>Hibernate does not support lazy initialization for "
"detached objects</emphasis>. This can be fixed by moving the code that reads "
"from the collection to just before the transaction is committed."
msgstr ""
"<literal>Session이 닫혔을 때 permissions 콜렉션이 초기화 되지 않았"
"으므로, 그 콜렉션은 그것의 상태를 로드시킬 수가 없을 것이다. "
"<emphasis>Hibernate 는 detached 객체들에 대한 lazy 초기화를 지원하지 않는다."
"</emphasis> 정정은 콜렉션으로부터 읽어들이는 코드를 커밋 바로 직전으로 이동시"
"키는 것이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Alternatively, you can use a non-lazy collection or association, by "
"specifying <literal>lazy=\"false\" for the association mapping. "
"However, it is intended that lazy initialization be used for almost all "
"collections and associations. If you define too many non-lazy associations "
"in your object model, Hibernate will fetch the entire database into memory "
"in every transaction."
msgstr ""
"다른 방법으로 연관 매핑에 대해 <literal>lazy=\"false\"를 지정함으로"
"써, non-lazy 콜렉션 또는 non-lazy 연관을 사용할 수 있다. 하지만 lazy 초기화"
"는 거의 모든 콜렉션들과 연관들에 대해 사용되도록 고안되어 있다. 만일 당신이 "
"당신의 객체 모형 내에 너무 많은 non-lazy 연관들을 정의할 경우, Hibernate는 모"
"든 트랜잭션에서 전체 데이터베이스를 메모리 속으로 페치하는 필요성을 끝내게 "
"될 것이다!"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"On the other hand, you can use join fetching, which is non-lazy by nature, "
"instead of select fetching in a particular transaction. We will now explain "
"how to customize the fetching strategy. In Hibernate3, the mechanisms for "
"choosing a fetch strategy are identical for single-valued associations and "
"collections."
msgstr ""
"다른 한편으로, 우리는 특정 트랜잭션 내에서 select 페칭 대신에 (고유하게 non-"
"lazy인) join 페칭을 선택하기를 자주 원한다. 우리는 이제 페칭 방도를 맞춤화 시"
"키는 방법을 알게 될 것이다. Hibernate3에서, 페치 방도를 선택하는 메커니즘은 "
"단일 값 연관들과 콜렉션들에 대해 동일하다."
#. Tag: title
#, no-c-format
msgid "Tuning fetch strategies"
msgstr "페치 방도들을 튜닝하기"
#. Tag: para
#, no-c-format
msgid ""
"Select fetching (the default) is extremely vulnerable to N+1 selects "
"problems, so we might want to enable join fetching in the mapping document:"
msgstr ""
"select 페칭(디폴트)은 N+1 selects 문제점들에 매우 취약해서, 우리는 매핑 문서"
"에서 join 페칭을 사용 가능하게 하기를 원할 수도 있다:"
#. Tag: para
#, no-c-format
msgid ""
"The <literal>fetch strategy defined in the mapping document "
"affects:"
msgstr ""
"매핑 문서 내에 정의된 <literal>fetch 방도는 다음에 영향을 준다:"
#. Tag: para
#, no-c-format
msgid "retrieval via <literal>get() or load()"
msgstr "<literal>get() 또는 load()를 통한 검색"
#. Tag: para
#, no-c-format
msgid "retrieval that happens implicitly when an association is navigated"
msgstr "연관이 네비게이트될 때 함축적으로 발생하는 검색"
#. Tag: para
#, no-c-format
msgid "<literal>Criteria queries"
msgstr "<literal>Criteria 질의들"
#. Tag: para
#, no-c-format
msgid "HQL queries if <literal>subselect fetching is used"
msgstr "<literal>subselect 페칭이 사용될 경우에 HQL 질의들"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Irrespective of the fetching strategy you use, the defined non-lazy graph is "
"guaranteed to be loaded into memory. This might, however, result in several "
"immediate selects being used to execute a particular HQL query."
msgstr ""
"당신이 사용하는 페칭 방도가 무엇인가에 상관없이, 정의된 비-lazy 그래프가 메모"
"리 내로 로드되는 것이 보장된다. 이것은 하나의 특별한 HQL 질의를 실행시키는데 "
"사용되는 몇몇 즉시적인 select들로 귀결될 수 있음을 노트하라."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Usually, the mapping document is not used to customize fetching. Instead, we "
"keep the default behavior, and override it for a particular transaction, "
"using <literal>left join fetch in HQL. This tells Hibernate to "
"fetch the association eagerly in the first select, using an outer join. In "
"the <literal>Criteria query API, you would use "
"<literal>setFetchMode(FetchMode.JOIN)."
msgstr ""
"대개, 우리는 페칭을 맞춤화 시키는데 매핑 문서를 사용하지 않는다. 대신에, 우리"
"는 디폴트 특징을 유지하고, HQL에서 <literal>left join fetch를 사용"
"하여, 특정 트랜잭션에 대해 그것을 오버라이드 시킨다. 이것은 outer join을 사용"
"하여 첫 번째 select에서 초기에 그 연관을 eagerly 페치시킬 것을 Hibernate에게 "
"알려준다. <literal>Criteria query API에서, 우리는 "
"<literal>setFetchMode(FetchMode.JOIN)을 사용한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If you want to change the fetching strategy used by <literal>get() "
"or <literal>load(), you can use a Criteria "
"query. For example:"
msgstr ""
"만일 당신이 <literal>get() 또는 load()에 의해 사"
"용된 페칭 방도를 변경시킬 수 있기를 당신이 원한다고 느낄 경우, 단순하게 "
"<literal>Criteria 질의를 사용하라. 예를 들면:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"This is Hibernate's equivalent of what some ORM solutions call a \"fetch plan"
"\"."
msgstr ""
"(이것은 몇몇 ORM 솔루션들이 \"페치 계획\"이라고 부르는 것에 대한 Hibernate의 "
"등가물이다.)"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A completely different approach to problems with N+1 selects is to use the "
"second-level cache."
msgstr ""
"N+1 개의 select들을 가진 문제점들을 피하는 완전히 다른 방법은 second-level 캐"
"시를 사용하는 것이다."
#. Tag: title
#, no-c-format
msgid "Single-ended association proxies"
msgstr "Single-ended 연관 프락시"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Lazy fetching for collections is implemented using Hibernate's own "
"implementation of persistent collections. However, a different mechanism is "
"needed for lazy behavior in single-ended associations. The target entity of "
"the association must be proxied. Hibernate implements lazy initializing "
"proxies for persistent objects using runtime bytecode enhancement which is "
"accessed via the CGLIB library."
msgstr ""
"콜렉션들에 대한 Lazy 페칭은 영속 콜렉션들에 대한 Hibernate 자신의 구현을 사용"
"하여 구현된다. 하지만 다른 메커니즘은 single-ended 연관들에서 lazy 특징에 필"
"요하다. 연관의 대상 엔티티는 프락시 되어야 한다. Hibernate는 (훌륭한 CGLIB 라"
"이브러리를 통해) 런타임 바이트코드 증진을 사용하여 영속 객체들에 대한 lazy 초"
"기화 프락시들을 구현한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"At startup, Hibernate3 generates proxies by default for all persistent "
"classes and uses them to enable lazy fetching of <literal>many-to-one"
"literal> and <literal>one-to-one associations."
msgstr ""
"디폴트로, Hibernate3는 모든 영속 클래스들에 대해 (시작 시에) 프락시들을 생성"
"시키고 <literal>many-to-one 연관과 one-to-one 연"
"관에 대해 lazy 페칭을 이용 가능하게 하는데 그것들을 사용한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The mapping file may declare an interface to use as the proxy interface for "
"that class, with the <literal>proxy attribute. By default, "
"Hibernate uses a subclass of the class. <emphasis>The proxied class must "
"implement a default constructor with at least package visibility. This "
"constructor is recommended for all persistent classes</emphasis>."
msgstr ""
"매핑 파일은 그 클래스에 대한 프락시 인터페이스로서 사용할, <literal>proxy"
"literal> 속성을 가진, 인터페이스를 선언할 수도 있다. 디폴트로 Hibernate는 그 "
"클래스의 서브클래스를 사용한다. <emphasis>프락시된 클래스는 최소한의 패키지 "
"가시성 (visibility)을 가진 디폴트 생성자를 구현해야 함을 노트하라. 우리는 모"
"든 영속 클래스들에 대해 이 생성자를 권장한다!</emphasis>"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"There are potential problems to note when extending this approach to "
"polymorphic classes.For example:"
msgstr ""
"다형성 클래스들에 대해 이 접근법을 확장할 때 의식해야 하는 몇몇 난처함들이 존"
"재한다. 예를 들면."
#. Tag: para
#, no-c-format
msgid ""
"Firstly, instances of <literal>Cat will never be castable to "
"<literal>DomesticCat, even if the underlying instance is an "
"instance of <literal>DomesticCat:"
msgstr ""
"첫 번째로, 심지어 기본 인스턴스가 <literal>DomesticCat의 인스턴스"
"인 경우조차도, <literal>Cat의 인스턴스들은 결코 "
"<literal>DomesticCat으로 타입캐스트가 가능하지 않을 것이다:"
#. Tag: para
#, fuzzy, no-c-format
msgid "Secondly, it is possible to break proxy <literal>==:"
msgstr "두번째로, 프락시 <literal>==를 파기할 가능성이 있다."
#. Tag: para
#, no-c-format
msgid ""
"However, the situation is not quite as bad as it looks. Even though we now "
"have two references to different proxy objects, the underlying instance will "
"still be the same object:"
msgstr ""
"하지만, 그 경우는 보이는 만큼 그렇게 나쁘지는 않다. 심지어 우리가 이제 다른 "
"프락시 객체들에 대한 두 개의 참조를 가질지라도, 기본 인스턴스는 여전히 동일"
"한 객체들일 것이다:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Third, you cannot use a CGLIB proxy for a <literal>final class or "
"a class with any <literal>final methods."
msgstr ""
"세번째로, 당신은 <literal>final 클래스 또는 임의의 final"
"literal> 메소드들을 가진 클래스에 대해 CGLIB 프락시를 사용하지 않을 수 있다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Finally, if your persistent object acquires any resources upon instantiation "
"(e.g. in initializers or default constructor), then those resources will "
"also be acquired by the proxy. The proxy class is an actual subclass of the "
"persistent class."
msgstr ""
"마지막으로, 만일 당신의 영속 객체가 초기화 시에 어떤 리소스들을 필요로 할 경"
"우(예를 들어, initializer들 또는 디폴트 생성자 내에서), 그때 그들 리소스들이 "
"또한 프락시에 의해 획득될 것이다. 프락시 클래스는 영속 클래스에 대한 실제 서"
"브클래스이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"These problems are all due to fundamental limitations in Java's single "
"inheritance model. To avoid these problems your persistent classes must each "
"implement an interface that declares its business methods. You should "
"specify these interfaces in the mapping file where <literal>CatImpl"
"literal> implements the interface <literal>Cat and "
"<literal>DomesticCatImpl implements the interface "
"<literal>DomesticCat. For example:"
msgstr ""
"이들 문제점들은 모두 자바의 단일 상속 모형의 기본적인 제약 때문이다. 만일 당"
"신이 이들 문제점들을 피하고자 원할 경우 당신의 영속 클래스들은 각각 그것의 비"
"지니스 메소드들을 선언하는 인터페이스를 구현해야 한다. 당신은 매핑 파일 속에 "
"이들 인터페이스들을 지정해야 한다. 예를 들면."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Then proxies for instances of <literal>Cat and "
"<literal>DomesticCat can be returned by load() "
"or <literal>iterate()."
msgstr ""
"첫 번째로, 심지어 기본 인스턴스가 <literal>DomesticCat의 인스턴스"
"인 경우조차도, <literal>Cat의 인스턴스들은 결코 "
"<literal>DomesticCat으로 타입캐스트가 가능하지 않을 것이다:"
#. Tag: title
#, no-c-format
msgid "Note"
msgstr ""
#. Tag: para
#, fuzzy, no-c-format
msgid "<literal>list() does not usually return proxies."
msgstr "<literal>Criteria 질의들"
#. Tag: para
#, no-c-format
msgid ""
"Relationships are also lazily initialized. This means you must declare any "
"properties to be of type <literal>Cat, not CatImpl"
"literal>."
msgstr ""
"관계들은 또한 lazy 초기화 된다. 이것은 당신이 임의의 프로퍼티들을 "
"<literal>CatImpl 타입이 아닌 Cat 타입으로 선언해"
"야 함을 의미한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Certain operations do <emphasis>not require proxy initialization:"
msgstr ""
"어떤 오퍼레이션들은 프락시 초기화를 필요로 하지 <emphasis>않는다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>equals(): if the persistent class does not override "
"<literal>equals()"
msgstr ""
"<literal>equals(), 만일 영속 클래스가 equals()"
"를 오버라이드 시키지 않는 경우"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>hashCode(): if the persistent class does not override "
"<literal>hashCode()"
msgstr ""
"<literal>hashCode(), 만일 영속 클래스가hashCode()"
"literal>를 오버라이드 시키지 않는 경우"
#. Tag: para
#, no-c-format
msgid "The identifier getter method"
msgstr "식별자 getter 메소드"
#. Tag: para
#, no-c-format
msgid ""
"Hibernate will detect persistent classes that override <literal>equals()"
"literal> or <literal>hashCode()."
msgstr ""
"Hibernate는 <literal>equals() 또는 hashCode()를 "
"오버라이드 시키는 영속 클래스들을 검출할 것이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"By choosing <literal>lazy=\"no-proxy\" instead of the default "
"<literal>lazy=\"proxy\", you can avoid problems associated with "
"typecasting. However, buildtime bytecode instrumentation is required, and "
"all operations will result in immediate proxy initialization."
msgstr ""
"디폴트 <literal>lazy=\"proxy\" 대신에 lazy=\"no-proxy\""
"literal>를 선택하여, 우리는 타입캐스팅과 연관된 문제점들을 피할 수 있다. 하지"
"만 우리는 빌드 시 바이트코드 수단을 필요로 할 것이고, 모든 연산들은 즉각적인 "
"프락시 초기화로 귀결될 것이다."
#. Tag: title
#, no-c-format
msgid "Initializing collections and proxies"
msgstr "콜렉션들과 프락시들을 초기화 시키기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A <literal>LazyInitializationException will be thrown by Hibernate "
"if an uninitialized collection or proxy is accessed outside of the scope of "
"the <literal>Session, i.e., when the entity owning the collection "
"or having the reference to the proxy is in the detached state."
msgstr ""
"만일 초기화 되지 않은 콜렉션이나 프락시가 <literal>Session 영역의 "
"외부에서 접근될 경우에, 예를 들어 콜렉션을 소유하거나 프락시에 대한 참조를 가"
"진 엔티티가 detached 상태에 있을 때, <literal>LazyInitializationException"
"literal>이 Hibernate에 의해 던져질 것이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Sometimes a proxy or collection needs to be initialized before closing the "
"<literal>Session. You can force initialization by calling "
"<literal>cat.getSex() or cat.getKittens().size()"
"literal>, for example. However, this can be confusing to readers of the code "
"and it is not convenient for generic code."
msgstr ""
"때때로 우리는<literal>Session을 닫기 전에 프락시 또는 콜렉션이 초기"
"화 됨을 확실히 할 필요가 있다. 물론 우리는 예를 들어 <literal>cat.getSex()"
"literal> 또는 <literal>cat.getKittens().size()를 호출하여 항상 초기"
"화를 강제시킬 수 있다. 그러나 그것은 코드의 독자들에게는 혼동스럽고 일반적인 "
"코드로 편의적이지 않다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The static methods <literal>Hibernate.initialize() and "
"<literal>Hibernate.isInitialized(), provide the application with a "
"convenient way of working with lazily initialized collections or proxies. "
"<literal>Hibernate.initialize(cat) will force the initialization "
"of a proxy, <literal>cat, as long as its Session"
"literal> is still open. <literal>Hibernate.initialize( cat.getKittens() )"
"literal> has a similar effect for the collection of kittens."
msgstr ""
"static 메소드들 <literal>Hibernate.initialize()와 "
"<literal>Hibernate.isInitialized()는 lazy 초기화 된 콜렉션들이나 프"
"락시들에 대해 작업하는 편리한 방법을 어플리케이션에 제공한다. "
"<literal>Hibernate.initialize(cat)은 그것의 Session"
"literal>이 여전히 열려져 있는 한 프락시 <literal>cat의 초기화를 강"
"제할 것이다. <literal>Hibernate.initialize( cat.getKittens())는 "
"kittens의 콜렉션에 대해 유사한 효과를 갖는다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Another option is to keep the <literal>Session open until all "
"required collections and proxies have been loaded. In some application "
"architectures, particularly where the code that accesses data using "
"Hibernate, and the code that uses it are in different application layers or "
"different physical processes, it can be a problem to ensure that the "
"<literal>Session is open when a collection is initialized. There "
"are two basic ways to deal with this issue:"
msgstr ""
"또 다른 옵션은 모든 필요한 콜렉션들과 프락시들이 로드되기 전까지 "
"<literal>Session을 열린 채로 유지하는 것이다. 몇몇 어플리케이션 아"
"키텍처들, 특히 Hibernate를 사용하여 데이터에 접근하는 코드, 그리고 다른 어플"
"리케이션 계층들이나 다른 물리적 프로세스들 내에서 그것을 사용하는 코드에서, "
"그것은 콜렉션이 초기화 될 때 <literal>Session이 열려져 있음을 확실"
"히 하는 문제일 수 있다. 이 쟁점을 다루는 두 가지 기본 방법들이 존재한다:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In a web-based application, a servlet filter can be used to close the "
"<literal>Session only at the end of a user request, once the "
"rendering of the view is complete (the <emphasis>Open Session in View"
"emphasis> pattern). Of course, this places heavy demands on the correctness "
"of the exception handling of your application infrastructure. It is vitally "
"important that the <literal>Session is closed and the transaction "
"ended before returning to the user, even when an exception occurs during "
"rendering of the view. See the Hibernate Wiki for examples of this \"Open "
"Session in View\" pattern."
msgstr ""
"웹 기반 어플리케이션에서, 서블릿 필터는 뷰 렌더링이 완료되는, 사용자 요청의 "
"바로 끝에서만 <literal>Session을 닫는데 사용될 수 있다"
"(<emphasis>Open Session in View 패턴). 물론 이것은 당신의 어플리케"
"이션 인프라스트럭처의 예외상황 처리의 정정에 관한 무거운 요구를 부과한다. 뷰 "
"렌더링 동안에 하나의 예외상황이 발생할때에도 사용자에게 반환되기 전에 "
"<literal>Session이 닫혀지고 트랜잭션이 종료되는 것은 지극히 중요하"
"다. 이 \"Open Session in View\" 패턴에 관한 예제들은 Hibernate 위키를 보라."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In an application with a separate business tier, the business logic must "
"\"prepare\" all collections that the web tier needs before returning. This "
"means that the business tier should load all the data and return all the "
"data already initialized to the presentation/web tier that is required for a "
"particular use case. Usually, the application calls <literal>Hibernate."
"initialize()</literal> for each collection that will be needed in the web "
"tier (this call must occur before the session is closed) or retrieves the "
"collection eagerly using a Hibernate query with a <literal>FETCH "
"clause or a <literal>FetchMode.JOIN in Criteria"
"literal>. This is usually easier if you adopt the <emphasis>Command"
"emphasis> pattern instead of a <emphasis>Session Facade."
msgstr ""
"별도의 비지니스 티어를 가진 어플리케이션에서, 비지니스 로직은 반환 전에 웹 티"
"어에 필요한 모든 콜렉션들을 \"준비\"해야 한다. 이것은 비지니스 티어가 모든 데"
"이터를 로드시키고 이미 초기화된 모든 데이터를 특정 쓰임새에 필요한 프리젠테이"
"션/웹 티어로 반환해야 함을 의미한다. 대개 어플리케이션은 웹 티어에 필요하게 "
"될 각각의 콜렉션에 대해 <literal>Hibernate.initialize()를 호출하거"
"나(이 호출은 세션이 닫히기 전에 발생해야 한다) 또는 <literal>FETCH "
"절을 갖거나 또는 <literal>Criteria 내에 FetchMode.JOIN"
"literal>을 가진 Hibernate 질의를 사용하여 콜렉션을 열심히 검색한다. 이것은 대"
"개 당신이 <emphasis>Session Facade 대신 Command"
"emphasis> 패턴을 채택할 경우에 더 쉽다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can also attach a previously loaded object to a new <literal>Session"
"literal> with <literal>merge() or lock() before "
"accessing uninitialized collections or other proxies. Hibernate does not, "
"and certainly <emphasis>should not, do this automatically since "
"it would introduce impromptu transaction semantics."
msgstr ""
"당신은 또한 초기화 되지 않은 콜렉션들(또는 다른 프락시들)에 접근하기 전에 "
"<literal>merge() 또는 lock()으로 앞서 로드된 객"
"체를 새로운 <literal>Sessionn에 첨부할 수도 있다. 아니다. Hibernate"
"는 이것을 자동적으로 행하지 않고, 확실히 자동적으로 행하지 <emphasis>않을 것"
"이다</emphasis>. 왜냐하면 그것은 특별한 목적을 위한 트랜잭션 의미를 도입할 것"
"이기 때문이다!"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Sometimes you do not want to initialize a large collection, but still need "
"some information about it, like its size, for example, or a subset of the "
"data."
msgstr ""
"때때로 당신은 거대한 콜렉션을 초기화 시키는 것을 원하지 않지만, 여전히 (그것"
"의 사이즈와 같은) 그것에 대한 어떤 정보 또는 데이터의 부분집합을 필요로 한다."
#. Tag: para
#, no-c-format
msgid ""
"You can use a collection filter to get the size of a collection without "
"initializing it:"
msgstr ""
"당신은 그것을 초기화 시키지 않고서 콜렉션의 사이즈를 얻는데 콜렉션 필터를 사"
"용할 수 있다:"
#. Tag: para
#, no-c-format
msgid ""
"The <literal>createFilter() method is also used to efficiently "
"retrieve subsets of a collection without needing to initialize the whole "
"collection:"
msgstr ""
"<literal>createFilter() 메소드는 또한 전체 콜렉션을 초기화 시킬 필"
"요 없이 콜렉션의 부분집합들을 효율적으로 검색하는데 사용된다:"
#. Tag: title
#, no-c-format
msgid "Using batch fetching"
msgstr "batch 페칭 사용하기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Using batch fetching, Hibernate can load several uninitialized proxies if "
"one proxy is accessed. Batch fetching is an optimization of the lazy select "
"fetching strategy. There are two ways you can configure batch fetching: on "
"the class level and the collection level."
msgstr ""
"Hibernate는 배치 페칭을 효율적으로 사용할 수 있다. 즉 하나의 프락시가 액세스 "
"될 경우에 Hibernate는 몇몇 초기화 되지 않은 프락시들을 로드시킬 수 있다(또는 "
"콜렉션들). batch 페칭은 lazy select 페칭 방도에 대한 최적화이다. 당신이 "
"batch 페칭을 튜닝시킬 수 있는 두 가지 방법들이 존재한다: 클래스 레벨에서 그리"
"고 콜렉션 레벨에서."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Batch fetching for classes/entities is easier to understand. Consider the "
"following example: at runtime you have 25 <literal>Cat instances "
"loaded in a <literal>Session, and each Cat has "
"a reference to its <literal>owner, a Person. "
"The <literal>Person class is mapped with a proxy, lazy="
"\"true\"</literal>. If you now iterate through all cats and call "
"<literal>getOwner() on each, Hibernate will, by default, execute "
"25 <literal>SELECT statements to retrieve the proxied owners. You "
"can tune this behavior by specifying a <literal>batch-size in the "
"mapping of <literal>Person:"
msgstr ""
"클래스들/엔티티들에 대한 batch 페칭은 이해하기가 더 쉽다. 당신이 실행 시에 다"
"음 상황에 처한다고 상상하라: 당신은 하나의 <literal>Session 속에 로"
"드된 25개의 <literal>Cat 인스턴스들을 갖고 있고, 각각의 "
"<literal>Cat은 그것의 소유자 즉, "
"<literal>Person에 대한 참조를 갖고 있다. Person "
"클래스는 프락시 <literal>lazy=\"true\"로서 매핑된다. 만일 당신이 이"
"제 모든 cat들을 통해 반복하고 각각의 cat에 대해 <literal>getOwner()"
"를 호출할 경우, Hibernate는 프락시된 소유자들을 검색하기 위해 25개의 "
"<literal>SELECT 문장들을 디폴트로 실행시킬 것이다. 당신은 "
"<literal>Person 매핑에서 batch-size를 지정함으로"
"써 이 동작을 튜닝시킬 수 있다:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate will now execute only three queries: the pattern is 10, 10, 5."
msgstr ""
"Hibernate는 이제 세 개의 질의들 만을 실행시킬 것이고, 그 패턴은 10,10, 5 이"
"다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can also enable batch fetching of collections. For example, if each "
"<literal>Person has a lazy collection of Cats, "
"and 10 persons are currently loaded in the <literal>Session, "
"iterating through all persons will generate 10 <literal>SELECTs, "
"one for every call to <literal>getCats(). If you enable batch "
"fetching for the <literal>cats collection in the mapping of "
"<literal>Person, Hibernate can pre-fetch collections:"
msgstr ""
"당신은 또한 콜렉션들에 대해 batch 페칭을 이용 가능하게 할 수도 있다. 예를 들"
"어, 만일 각각의 <literal>Person이 Cat들을 가진 "
"lazy 콜렉션을 갖고, 10개의 person들이 <literal>Sesssion 내에 현재 "
"로드되어 있을 경우, 모든 person들에 대한 반복은 10개의 <literal>SELECT"
"literal>들을 생성시킬 것이고, <literal>getCats()에 대한 매번의 호출"
"에 대해 하나의 <literal>SELECT를 생성시킬 것이다. 만일 당신이 "
"<literal>Person 매핑에서 cats 콜렉션에 대해 "
"batch 페칭을 사용가능하게 할 경우, Hibernate는 콜렉션들을 미리-페치 시킬 수 "
"있다:"
#. Tag: para
#, no-c-format
msgid ""
"With a <literal>batch-size of 3, Hibernate will load 3, 3, 3, 1 "
"collections in four <literal>SELECTs. Again, the value of the "
"attribute depends on the expected number of uninitialized collections in a "
"particular <literal>Session."
msgstr ""
"<literal>batch-size 8로서, Hibernate는 4개의 SELECT들에서 3, 3, 3, "
"1 개의 콜렉션들을 로드시킬 것이다. 다시 그 속성의 값은 특정 "
"<literal>Session 내에서 초기화 되지 않은 콜렉션들의 예상되는 개수"
"에 의존한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Batch fetching of collections is particularly useful if you have a nested "
"tree of items, i.e. the typical bill-of-materials pattern. However, a "
"<emphasis>nested set or a materialized path "
"might be a better option for read-mostly trees."
msgstr ""
"만일 당신이 항목들의 포개진 트리를 가질 경우, 예를 들어 전형적인 bill-of-"
"materials 패턴인 경우, (비록 <emphasis>내포된 set 또는 "
"실체화된 경로(materialized path)</emphasis>가 주로-읽기-트리들에 대해 더 좋"
"은 옵션일 수 있을지라도) 콜렉션들에 대한 batch 페칭이 특히 유용하다."
#. Tag: title
#, no-c-format
msgid "Using subselect fetching"
msgstr "subselect 페칭 사용하기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If one lazy collection or single-valued proxy has to be fetched, Hibernate "
"will load all of them, re-running the original query in a subselect. This "
"works in the same way as batch-fetching but without the piecemeal loading."
msgstr ""
"만일 한 개의 lazy 콜렉션이나 단일 값 프락시가 페치되어야 한다면, Hibernate는 "
"하나의 subselect 내에서 원래의 질의를 다시 실행하여 그것들 모두를 로드시킨"
"다. 이것은 조각난 로딩 없이 batch 페칭과 동일한 방식으로 동작한다."
#. Tag: title
#, fuzzy, no-c-format
msgid "Fetch profiles"
msgstr "페칭 방도들"
#. Tag: para
#, no-c-format
msgid ""
"Another way to affect the fetching strategy for loading associated objects "
"is through something called a fetch profile, which is a named configuration "
"associated with the <interfacename>org.hibernate.SessionFactory"
"interfacename> but enabled, by name, on the <interfacename>org.hibernate."
"Session</interfacename>. Once enabled on a org.hibernate."
"Session</interfacename>, the fetch profile wull be in affect for that "
"<interfacename>org.hibernate.Session until it is explicitly "
"disabled."
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"So what does that mean? Well lets explain that by way of an example. Say we "
"have the following mappings:"
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"Now normally when you get a reference to a particular customer, that "
"customer's set of orders will be lazy meaning we will not yet have loaded "
"those orders from the database. Normally this is a good thing. Now lets say "
"that you have a certain use case where it is more efficient to load the "
"customer and their orders together. One way certainly is to use \"dynamic "
"fetching\" strategies via an HQL or criteria queries. But another option is "
"to use a fetch profile to achieve that. Just add the following to your "
"mapping:"
msgstr ""
#. Tag: para
#, no-c-format
msgid "or even:"
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"Now the following code will actually load both the customer <emphasis>and "
"their orders</emphasis>:"
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"Currently only join style fetch profiles are supported, but they plan is to "
"support additional styles. See <ulink url=\"http://opensource.atlassian.com/"
"projects/hibernate/browse/HHH-3414\">HHH-3414</ulink> for details."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Using lazy property fetching"
msgstr "lazy 프로퍼티 페칭 사용하기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate3 supports the lazy fetching of individual properties. This "
"optimization technique is also known as <emphasis>fetch groups. "
"Please note that this is mostly a marketing feature; optimizing row reads is "
"much more important than optimization of column reads. However, only loading "
"some properties of a class could be useful in extreme cases. For example, "
"when legacy tables have hundreds of columns and the data model cannot be "
"improved."
msgstr ""
"Hibernate3은 개별적인 프로퍼티들에 대한 lazy 페칭을 지원한다. 이 최적화 기술"
"은 또한 <emphasis>fetch groups 으로 알려져 있다. 이것이 대개 마케"
"팅 특징임을 노트하길 바란다. 왜냐하면 실제로 행 읽기를 최적화 시키는 것이 컬"
"럼 읽기에 대한 최적화 보다 훨씬 더 중요하기 때문이다. 하지만 리거시 테이블들"
"이 수백 개의 컬럼들을 갖고 데이터 모형이 개선될 수 없을 때, 오직 클래스의 몇"
"몇 프로퍼티들을 로드시키는 것 만이 유용할 수도 있다."
#. Tag: para
#, no-c-format
msgid ""
"To enable lazy property loading, set the <literal>lazy attribute "
"on your particular property mappings:"
msgstr ""
"lazy 프로퍼티 로딩을 이용가능하게 하려면, 당신의 특정 property 매핑들에 대해 "
"<literal>lazy 속성을 설정하라:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Lazy property loading requires buildtime bytecode instrumentation. If your "
"persistent classes are not enhanced, Hibernate will ignore lazy property "
"settings and return to immediate fetching."
msgstr ""
"Lazy property 로딩은 빌드 시 바이트코드 수단을 필요로 한다! 만일 당신의 영속 "
"클래스들이 개선되지 않을 경우, Hibernate는 조용하게 lazy 프로퍼티 설정들을 무"
"시하고 즉각적인 페칭으로 후퇴할 것이다."
#. Tag: para
#, no-c-format
msgid "For bytecode instrumentation, use the following Ant task:"
msgstr "bytecode 수단으로, 다음 Ant 태스크를 사용하라:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A different way of avoiding unnecessary column reads, at least for read-only "
"transactions, is to use the projection features of HQL or Criteria queries. "
"This avoids the need for buildtime bytecode processing and is certainly a "
"preferred solution."
msgstr ""
"불필요한 컬럼 읽기를 피하는 다른 (더 좋은?) 방법은 적어도 읽기 전용 트랜잭션"
"의 경우에 HQL 질의 또는 Criteria 질의의 투사(projection) 특징들을 사용하는 것"
"이다. 이것은 빌드 시 바이트코드 처리에 대한 필요성을 피하게 해주고 확실히 선"
"호되는 해결책이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can force the usual eager fetching of properties using <literal>fetch "
"all properties</literal> in HQL."
msgstr ""
"당신은 HQL에서 <literal>fetch all properties를 사용하여 프로퍼티들"
"에 대한 통상의 eager 페칭을 강제시킬 수 있다."
#. Tag: title
#, no-c-format
msgid "The Second Level Cache"
msgstr "두번째 레벨 캐시"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A Hibernate <literal>Session is a transaction-level cache of "
"persistent data. It is possible to configure a cluster or JVM-level "
"(<literal>SessionFactory-level) cache on a class-by-class and "
"collection-by-collection basis. You can even plug in a clustered cache. Be "
"aware that caches are not aware of changes made to the persistent store by "
"another application. They can, however, be configured to regularly expire "
"cached data."
msgstr ""
"Hibernate <literal>Session은 영속 데이터에 대한 트랜잭션 레벨 캐시"
"이다. class-by-class와 collection-by-collection 기반 위에 클러스터 또는 JVM-"
"레벨(<literal>SessionFactory-레벨) 캐시를 구성하는 것이 가능하다. "
"당신은 클러스터링 된 캐시 속에 플러그인 할 수도 있다. 주의하라. 캐시들은 (비"
"록 그것들이 캐시된 데이터를 정기적으로 만료되도록 구성되어 있을지라도) 또 다"
"른 어플리케이션에 의해 영속 저장소에 대해 행해진 변경들을 결코 알지 못한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You have the option to tell Hibernate which caching implementation to use by "
"specifying the name of a class that implements <literal>org.hibernate.cache."
"CacheProvider</literal> using the property hibernate.cache."
"provider_class</literal>. Hibernate is bundled with a number of built-in "
"integrations with the open-source cache providers that are listed below. You "
"can also implement your own and plug it in as outlined above. Note that "
"versions prior to 3.2 use EhCache as the default cache provider."
msgstr ""
"디폴트로, Hibernate는 JVM-레벨의 캐싱에 EHCache를 사용한다. (JCS 지원은 이제 "
"진부하게 되었고 Hibernate의 장래 버전에서 제거될 것이다.) 당신은 "
"<literal>hibernate.cache.provider_class 프로퍼티를 사용하여 "
"<literal>org.hibernate.cache.CacheProvider를 구현하는 클래스의 이름"
"을 지정함으로써 다른 구현을 선택할 수도 있다. You have the option to tell "
"Hibernate which caching implementation to use by specifying the name of a "
"class that implements <literal>org.hibernate.cache.CacheProvider "
"using the property <literal>hibernate.cache.provider_class. "
"Hibernate comes bundled with a number of built-in integrations with open-"
"source cache providers (listed below); additionally, you could implement "
"your own and plug it in as outlined above. Note that versions prior to 3.2 "
"defaulted to use EhCache as the default cache provider; that is no longer "
"the case as of 3.2. 당신은 <literal>hibernate.cache.provider_class "
"프로퍼티를 사용하여 <literal>org.hibernate.cache.CacheProvider를 구"
"현하는 클래스의 이름을 지정함으로써 어느 캐싱 구현을 사용할 것인지를 "
"Hibernate에게 알려주는 옵션을 갖는다. Hibernate는 (아래에 열거된) 오픈-소스 "
"프로바이더들을 가진 많은 빌드되어 있는 통합들을 번들로 갖고 있다; 추가적으로 "
"당신은 위에서 언급했듯이 그것에 당신 자신의 것을 구현할 수 있고 그것에 플러"
"그 시킬 수 있다. 3.2 이번 버전들은 디플트 캐시 프로바이더로서 EhCache를 사용"
"하도록 디포릍로 내장되어 있음을 노트하라; 버전 3.2의 경우에 그것은 더이상 디"
"폴트 내장이 아니다."
#. Tag: title
#, no-c-format
msgid "Cache Providers"
msgstr "캐시 프로바이더들"
#. Tag: entry
#, no-c-format
msgid "Cache"
msgstr "캐시"
#. Tag: entry
#, no-c-format
msgid "Provider class"
msgstr "프로바이더 클래스"
#. Tag: entry
#, no-c-format
msgid "Type"
msgstr "타입"
#. Tag: entry
#, no-c-format
msgid "Cluster Safe"
msgstr "클러스터 안전"
#. Tag: entry
#, no-c-format
msgid "Query Cache Supported"
msgstr "질의 캐시 지원"
#. Tag: entry
#, fuzzy, no-c-format
msgid "Hashtable (not intended for production use)"
msgstr ""
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"Hashtable (제품 용도로 고안되어 있지 않음)\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"Hashtable (제품용으로 고안되지 않음)"
#. Tag: entry
#, fuzzy, no-c-format
msgid "<literal>org.hibernate.cache.HashtableCacheProvider"
msgstr "org.hibernate.cache.HashtableCacheProvider"
#. Tag: entry
#, no-c-format
msgid "memory"
msgstr "memory"
#. Tag: entry
#, fuzzy, no-c-format
msgid "yes"
msgstr ""
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"yes\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"yes\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"yes\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예\n"
"#-#-#-#-# - (PACKAGE VERSION) #-#-#-#-#\n"
"예"
#. Tag: entry
#, no-c-format
msgid "EHCache"
msgstr "EHCache"
#. Tag: entry
#, fuzzy, no-c-format
msgid "<literal>org.hibernate.cache.EhCacheProvider"
msgstr "org.hibernate.cache.EhCacheProvider"
#. Tag: entry
#, no-c-format
msgid "memory, disk"
msgstr "memory, disk"
#. Tag: entry
#, no-c-format
msgid "OSCache"
msgstr "OSCache"
#. Tag: entry
#, fuzzy, no-c-format
msgid "<literal>org.hibernate.cache.OSCacheProvider"
msgstr "org.hibernate.cache.OSCacheProvider"
#. Tag: entry
#, no-c-format
msgid "SwarmCache"
msgstr "SwarmCache"
#. Tag: entry
#, fuzzy, no-c-format
msgid "<literal>org.hibernate.cache.SwarmCacheProvider"
msgstr "org.hibernate.cache.SwarmCacheProvider"
#. Tag: entry
#, no-c-format
msgid "clustered (ip multicast)"
msgstr "clustered (ip multicast)"
#. Tag: entry
#, no-c-format
msgid "yes (clustered invalidation)"
msgstr "yes (clustered invalidation)"
#. Tag: entry
#, fuzzy, no-c-format
msgid "JBoss Cache 1.x"
msgstr "JBoss TreeCache"
#. Tag: entry
#, fuzzy, no-c-format
msgid "<literal>org.hibernate.cache.TreeCacheProvider"
msgstr "org.hibernate.cache.TreeCacheProvider"
#. Tag: entry
#, no-c-format
msgid "clustered (ip multicast), transactional"
msgstr "clustered (ip multicast), transactional"
#. Tag: entry
#, no-c-format
msgid "yes (replication)"
msgstr "yes (replication)"
#. Tag: entry
#, no-c-format
msgid "yes (clock sync req.)"
msgstr "yes (clock sync req.)"
#. Tag: entry
#, fuzzy, no-c-format
msgid "JBoss Cache 2"
msgstr "JBoss TreeCache"
#. Tag: entry
#, fuzzy, no-c-format
msgid "<literal>org.hibernate.cache.jbc.JBossCacheRegionFactory"
msgstr "org.hibernate.cache.EhCacheProvider"
#. Tag: entry
#, fuzzy, no-c-format
msgid "yes (replication or invalidation)"
msgstr "yes (clustered invalidation)"
#. Tag: title
#, no-c-format
msgid "Cache mappings"
msgstr "Cache 매핑들"
#. Tag: para
#, no-c-format
msgid ""
"The <literal><cache> element of a class or collection "
"mapping has the following form:"
msgstr ""
"클래스 또는 콜렉션 매핑의 <literal><cache> 요소는 다음 형식"
"을 갖는다:"
#. Tag: para
#, no-c-format
msgid ""
"<literal>usage (required) specifies the caching strategy: "
"<literal>transactional, read-write, "
"<literal>nonstrict-read-write or read-only"
msgstr ""
"<literal>usage(필수) 캐싱 방도를 지정한다: transactional"
"literal>, <literal>read-write, nonstrict-read-write"
"literal> 또는 <literal>read-only"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>region (optional: defaults to the class or collection "
"role name): specifies the name of the second level cache region"
msgstr ""
"<literal>region (옵션, 디폴트는 class 또는 콜렉션 role 이름) "
"second level 캐시 영역의 이름을 지정한다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>include (optional: defaults to all) "
"<literal>non-lazy: specifies that properties of the entity mapped "
"with <literal>lazy=\"true\" cannot be cached when attribute-level "
"lazy fetching is enabled"
msgstr ""
"<literal>include (옵션, 디폴트는 all) "
"<literal>non-lazy는 lazy=\"true\"로 매핑된 엔티"
"티의 프로퍼티들을 지정하며 속성-레벨 lazy 페칭이 이용 가능할 때 키시될 수 없"
"다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Alternatively, you can specify <literal><class-cache> and "
"<literal><collection-cache> elements in hibernate."
"cfg.xml</literal>."
msgstr ""
"다른 방법으로 (선호적으로?), 당신은 <literal>hibernate.cfg.xml 내"
"에 <literal><class-cache>와 <collection-cache>"
"</literal> 요소들을 지정할 수도 있다."
#. Tag: para
#, no-c-format
msgid ""
"The <literal>usage attribute specifies a cache "
"concurrency strategy</emphasis>."
msgstr ""
"<literal>usage 속성은 캐시 동시성 방도를 지정"
"한다."
#. Tag: title
#, no-c-format
msgid "Strategy: read only"
msgstr "방도: 읽기 전용"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If your application needs to read, but not modify, instances of a persistent "
"class, a <literal>read-only cache can be used. This is the "
"simplest and optimal performing strategy. It is even safe for use in a "
"cluster."
msgstr ""
"당신의 어플리케이션이 영속 클래스의 인스턴스들을 읽어들일 필요가 있지만 결코 "
"변경할 필요가 없을 경우에 <literal>read-only 캐시가 사용될 수 있"
"다. 이것은 가장 간단한 최상의 퍼포먼스를 위한 방도이다. 그것은 클러스터 내 사"
"용에는 완벽하게 안전하다."
#. Tag: title
#, no-c-format
msgid "Strategy: read/write"
msgstr "방도: 읽기/쓰기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If the application needs to update data, a <literal>read-write "
"cache might be appropriate. This cache strategy should never be used if "
"serializable transaction isolation level is required. If the cache is used "
"in a JTA environment, you must specify the property <literal>hibernate."
"transaction.manager_lookup_class</literal> and naming a strategy for "
"obtaining the JTA <literal>TransactionManager. In other "
"environments, you should ensure that the transaction is completed when "
"<literal>Session.close() or Session.disconnect()"
"literal> is called. If you want to use this strategy in a cluster, you "
"should ensure that the underlying cache implementation supports locking. The "
"built-in cache providers <emphasis>do not support locking."
msgstr ""
"어플리케이션이 데이터를 업데이트 할 필요가 있을 경우, <literal>read-write"
"literal> 캐시가 적절하다. 만일 직렬화 가능한(serializable) 트랜잭션 격리 레벨"
"이 필요한 경우에는 이 캐시 방도가 결코 사용되지 말아야 한다. 만일 캐시가 JTA "
"환경에서 사용될 경우, 당신은 JTA <literal>TransactionManager를 얻"
"는 방도를 명명하는 <literal>hibernate.transaction.manager_lookup_class"
"literal> 프로퍼티를 지정해야 한다. 다른 환경들에서, 당신은<literal>Session."
"close()</literal> 또는 Session.disconnect()가 호출될 때 트"
"랜잭션이 완료되는 것을 확실히 해야 한다. 만일 당신이 클러스터 내에 이 방도를 "
"사용하고자 원할 경우, 당신은 기본 캐시 구현이 잠금을 지원하도록 하는 것을 확"
"실히 해야 한다. 미리 만들어진 캐시 프로바이더들은 그렇게 행하지 <emphasis>않"
"는다</emphasis>."
#. Tag: title
#, no-c-format
msgid "Strategy: nonstrict read/write"
msgstr "방도: 엄격하지 않은 읽기/쓰기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If the application only occasionally needs to update data (i.e. if it is "
"extremely unlikely that two transactions would try to update the same item "
"simultaneously), and strict transaction isolation is not required, a "
"<literal>nonstrict-read-write cache might be appropriate. If the "
"cache is used in a JTA environment, you must specify <literal>hibernate."
"transaction.manager_lookup_class</literal>. In other environments, you "
"should ensure that the transaction is completed when <literal>Session.close()"
"</literal> or Session.disconnect() is called."
msgstr ""
"만일 어플리케이션이 오직 데이터를 자주 업데이트할 필요가 있고(예를 들어, 만"
"일 두 개의 트랜잭션들이 동시에 동일한 항목을 업데이트 하려고 시도하는 정말 있"
"음직하지 않은 경우) 그리고 엄격한 트랜잭션 격리가 필요하지 않은 경우, "
"<literal>nonstrict-read-write 캐시가 적절할 수 있다. 만일 그 캐시"
"가 JTA 환경에서 사용될 경우, 당신은 <literal>hibernate.transaction."
"manager_lookup_class</literal>를 지정해야 한다. 다른 환경들에서, 당신은 "
"<literal>Session.close() 또는 Session.disconnect()"
"literal>가 호출될 때 트랜잭션이 완료되도록 확실히 해야 한다."
#. Tag: title
#, no-c-format
msgid "Strategy: transactional"
msgstr "방도: transactional"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>transactional cache strategy provides support for "
"fully transactional cache providers such as JBoss TreeCache. Such a cache "
"can only be used in a JTA environment and you must specify "
"<literal>hibernate.transaction.manager_lookup_class."
msgstr ""
"<literal>transactional 캐시 방도는 JBoss TreeCache와 같은 전체 트랜"
"잭션적인 캐시 프로바이더들에 대한 지원을 제공한다. 그런 캐시는 오직 JTA 환경 "
"내에서 사용될 수 있고 당신은 <literal>hibernate.transaction."
"manager_lookup_class</literal>를 지정해야 한다."
#. Tag: title
#, fuzzy, no-c-format
msgid "Cache-provider/concurrency-strategy compatibility"
msgstr "캐시 동시성 방도 지원"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"None of the cache providers support all of the cache concurrency strategies."
msgstr ""
"캐시 프로바이더들 중 어느 것도 모든 캐시 동시성 방도들을 지원하지 않는다. 다"
"음 테이블은 어느 프로바이더들이 어느 동시성 방도들과 호환되는지를 보여준다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The following table shows which providers are compatible with which "
"concurrency strategies."
msgstr ""
"캐시 프로바이더들 중 어느 것도 모든 캐시 동시성 방도들을 지원하지 않는다. 다"
"음 테이블은 어느 프로바이더들이 어느 동시성 방도들과 호환되는지를 보여준다."
#. Tag: title
#, no-c-format
msgid "Cache Concurrency Strategy Support"
msgstr "캐시 동시성 방도 지원"
#. Tag: entry
#, no-c-format
msgid "read-only"
msgstr "읽기 전용"
#. Tag: entry
#, no-c-format
msgid "nonstrict-read-write"
msgstr "엄격하지 않은 읽기-쓰기"
#. Tag: entry
#, no-c-format
msgid "read-write"
msgstr "읽기-쓰기"
#. Tag: entry
#, no-c-format
msgid "transactional"
msgstr "transactional"
#. Tag: title
#, no-c-format
msgid "Managing the caches"
msgstr "캐시들을 관리하기"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Whenever you pass an object to <literal>save(), update()"
"literal> or <literal>saveOrUpdate(), and whenever you retrieve an "
"object using <literal>load(), get(), "
"<literal>list(), iterate() or scroll()"
"</literal>, that object is added to the internal cache of the "
"<literal>Session."
msgstr ""
"당신이 객체를 <literal>save(), update() 또는 "
"<literal>saveOrUpdate()에 전달할 때마다 그리고 당신이 load"
"()</literal>, get(), list(), "
"<literal>iterate() 또는 scroll()을 사용하여 객체"
"를 검색할 때마다, 그 객체는 <literal>Session의 내부 캐시에 추가된"
"다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"When <literal>flush() is subsequently called, the state of that "
"object will be synchronized with the database. If you do not want this "
"synchronization to occur, or if you are processing a huge number of objects "
"and need to manage memory efficiently, the <literal>evict() method "
"can be used to remove the object and its collections from the first-level "
"cache."
msgstr ""
"<literal>flush()가 차후적으로 호출될 때, 그 객체의 상태는 데이터베"
"이스와 동기화 될 것이다. 만일 당신이 이 동기화가 발생되는 것을 원하지 않거나 "
"만일 당신이 대량의 객체들을 처리 중이고 메모리를 효율적으로 관리할 필요가 있"
"을 경우, <literal>evict() 메소드는 first-level 캐시로부터 그 객체"
"와 그것의 콜렉션들을 제거하는데 사용될 수 있다."
#. Tag: para
#, no-c-format
msgid ""
"The <literal>Session also provides a contains() "
"method to determine if an instance belongs to the session cache."
msgstr ""
"<literal>Session은 또한 인스턴스가 세션 캐시에 속하는지 여부를 결정"
"하는데 <literal>contains() 메소드를 제공한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"To evict all objects from the session cache, call <literal>Session.clear()"
"literal>"
msgstr ""
"세션 캐시로부터 모든 객체들을 완전하게 퇴거시키기 위해, <literal>Session."
"clear()</literal>를 호출하라."
#. Tag: para
#, no-c-format
msgid ""
"For the second-level cache, there are methods defined on "
"<literal>SessionFactory for evicting the cached state of an "
"instance, entire class, collection instance or entire collection role."
msgstr ""
"second-level 캐시의 경우, 하나의 인스턴스, 전체 클래스, 콜렉션 인스턴스 또는 "
"전체 콜렉션 role의 캐시된 상태를 퇴거시키는 <literal>SessionFactory"
"literal> 상에 정의된 메소드들이 존재한다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>CacheMode controls how a particular session interacts "
"with the second-level cache:"
msgstr ""
"<literal>CacheMode는 특정 세션이 second-level 캐시와 어떻게 상호작"
"용하는지를 제어한다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>CacheMode.NORMAL: will read items from and write items to "
"the second-level cache"
msgstr ""
"<literal>CacheMode.NORMAL - second-level 캐시로부터 아이템들을 읽어"
"들이고 second-level 캐시로 아이템들을 기록한다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>CacheMode.GET: will read items from the second-level "
"cache. Do not write to the second-level cache except when updating data"
msgstr ""
"<literal>CacheMode.GET - second-level 캐시로부터 아이템들을 읽어들"
"이지만, 데이터를 업데이트할 때를 제외하면 second-level 캐시로 기록하지 않는다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>CacheMode.PUT: will write items to the second-level "
"cache. Do not read from the second-level cache"
msgstr ""
"<literal>CacheMode.PUT - 아이템들을 second-level 캐시에 기록하지"
"만, second-level 캐시로부터 읽어들이지 않는다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>CacheMode.REFRESH: will write items to the second-level "
"cache. Do not read from the second-level cache. Bypass the effect of "
"<literal>hibernate.cache.use_minimal_puts forcing a refresh of the "
"second-level cache for all items read from the database"
msgstr ""
"<literal>CacheMode.REFRESH - 아이템들을 second-level 캐시로기록하지"
"만, second-level 캐시로부터 읽어들이지 않고, 데이터베이스로부터 읽어들인 모"
"든 아이템들에 대한 second-level 캐시의 갱신을 강제시켜, <literal>hibernate."
"cache.use_minimal_puts</literal>의 효과를 무시한다"
#. Tag: para
#, no-c-format
msgid ""
"To browse the contents of a second-level or query cache region, use the "
"<literal>Statistics API:"
msgstr ""
"second-level 캐시 또는 질의 캐시 영역의 내용물을 브라우징하려면 "
"<literal>Statistics API를 사용하라:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You will need to enable statistics and, optionally, force Hibernate to keep "
"the cache entries in a more readable format:"
msgstr ""
"당신은 통계를 이용 가능하게 하고, 선택적으로 Hibernate로 하여금 캐시 엔트리들"
"을 보다 인간에게 이해가능한 형식으로 유지시키도록 강제시키는 것이 필요할 것이"
"다:"
#. Tag: title
#, no-c-format
msgid "The Query Cache"
msgstr "질의 캐시"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Query result sets can also be cached. This is only useful for queries that "
"are run frequently with the same parameters."
msgstr ""
"질의 결과 셋들이 또한 캐시될 수도 있다. 이것은 동일한 파라미터들을 가지고 자"
"주 실행되는 질의들에만 유용하다. 질의 캐시를 사용하기 위해 당신은 먼저 그것"
"을 이용 가능하도록 해야 한다:"
#. Tag: title
#, no-c-format
msgid "Enabling query caching"
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"Caching of query results introduces some overhead in terms of your "
"applications normal transactional processing. For example, if you cache "
"results of a query against Person Hibernate will need to keep track of when "
"those results should be invalidated because changes have been committed "
"against Person. That, coupled with the fact that most applications simply "
"gain no benefit from caching query results, leads Hibernate to disable "
"caching of query results by default. To use query caching, you will first "
"need to enable the query cache:"
msgstr ""
#. Tag: para
#, no-c-format
msgid "This setting creates two new cache regions:"
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"<classname>org.hibernate.cache.StandardQueryCache, holding the "
"cached query results"
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"<classname>org.hibernate.cache.UpdateTimestampsCache, holding "
"timestamps of the most recent updates to queryable tables. These are used to "
"validate the results as they are served from the query cache."
msgstr ""
#. Tag: para
#, no-c-format
msgid ""
"If you configure your underlying cache implementation to use expiry or "
"timeouts is is very important that the cache timeout of the underlying cache "
"region for the UpdateTimestampsCache be set to a higher value than the "
"timeouts of any of the query caches. In fact, we recommend that the the "
"UpdateTimestampsCache region not be configured for expiry at all. Note, in "
"particular, that an LRU cache expiry policy is never appropriate."
msgstr ""
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"As mentioned above, most queries do not benefit from caching or their "
"results. So by default, individual queries are not cached even after "
"enabling query caching. To enable results caching for a particular query, "
"call <literal>org.hibernate.Query.setCacheable(true). This call "
"allows the query to look for existing cache results or add its results to "
"the cache when it is executed."
msgstr ""
"대부분의 질의들은 캐싱으로부터 이점이 없기에, 디폴트로 질의들은 캐시되지 않는"
"다. 캐싱을 이용 가능하도록 하려면, <literal>Query.setCacheable(true)"
"literal>를 호출하라. 이 호출은 기존 캐시 결과들을 찾는 것을 질의에게 허용해주"
"거나 질의가 실행될 때 그것의 결과들을 캐시에 추가하는 것을 허용해준다."
#. Tag: para
#, no-c-format
msgid ""
"The query cache does not cache the state of the actual entities in the "
"cache; it caches only identifier values and results of value type. For this "
"reaso, the query cache should always be used in conjunction with the second-"
"level cache for those entities expected to be cached as part of a query "
"result cache (just as with collection caching)."
msgstr ""
#. Tag: title
#, fuzzy, no-c-format
msgid "Query cache regions"
msgstr "질의 캐시 지원"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If you require fine-grained control over query cache expiration policies, "
"you can specify a named cache region for a particular query by calling "
"<literal>Query.setCacheRegion()."
msgstr ""
"만일 당신이 질의 캐시 만료 정책들에 대한 세밀한 제어를 필요로 할 경우, 당신"
"은 <literal>Query.setCacheRegion()을 호출함으로써 특별한 질의에 대"
"해 명명되니 캐시 영역을 지정할 수도 있다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If you want to force the query cache to refresh one of its regions "
"(disregard any cached results it finds there) you can use <literal>org."
"hibernate.Query.setCacheMode(CacheMode.REFRESH)</literal>. In conjunction "
"with the region you have defined for the given query, Hibernate will "
"selectively force the results cached in that particular region to be "
"refreshed. This is particularly useful in cases where underlying data may "
"have been updated via a separate process and is a far more efficient "
"alternative to bulk eviction of the region via <literal>org.hibernate."
"SessionFactory.evictQueries()</literal>."
msgstr ""
"만일 질의가 그것의 질의 캐시 영역의 갱신을 강제시켜야 하는 경우에, 당신은 "
"<literal>Query.setCacheMode(CacheMode.REFRESH)를 호출해야 한다. 이"
"것은 기본 데이터가 별도의 프로세스를 통해 업데이트되었고(예를 들면, Hibernate"
"를 통해 변경되지 않았고) 특정 질의 결과 셋들을 선택적으로 갱신하는 것을 어플"
"리케이션에게 허용해주는 경우들에서 특별히 유용하다. 이것은 "
"<literal>SessionFactory.evictQueries()를 통해 질의 캐시 영역을 퇴거"
"시키는 보다 효과적인 대안이다."
#. Tag: title
#, no-c-format
msgid "Understanding Collection performance"
msgstr "콜렉션 퍼포먼스 이해하기"
#. Tag: para
#, no-c-format
msgid ""
"In the previous sections we have covered collections and their applications. "
"In this section we explore some more issues in relation to collections at "
"runtime."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Taxonomy"
msgstr "분류"
#. Tag: para
#, no-c-format
msgid "Hibernate defines three basic kinds of collections:"
msgstr "Hibernate는 세 가지 기본적인 종류의 콜렉션들을 정의한다:"
#. Tag: para
#, no-c-format
msgid "collections of values"
msgstr "값들을 가진 콜렉션들"
#. Tag: para
#, fuzzy, no-c-format
msgid "one-to-many associations"
msgstr "one to many 연관들"
#. Tag: para
#, fuzzy, no-c-format
msgid "many-to-many associations"
msgstr "many to many 연관들"
#. Tag: para
#, no-c-format
msgid ""
"This classification distinguishes the various table and foreign key "
"relationships but does not tell us quite everything we need to know about "
"the relational model. To fully understand the relational structure and "
"performance characteristics, we must also consider the structure of the "
"primary key that is used by Hibernate to update or delete collection rows. "
"This suggests the following classification:"
msgstr ""
"이 분류는 여러 가지 테이블과 foreign key 관계들을 구별짓지만 우리가 관계형 모"
"형에 대해 알 필요가 있는 모든 것을 우리에게 말해주지 않는다. 관계형 구조와 퍼"
"포먼스 특징들을 완전하게 이해하기 위해, 우리는 또한 콜렉션 행들을 업데이트하"
"거나 삭제하기 위해 Hibernate에 의해 사용되는 프라이머리 키의 구조를 검토해야 "
"한다. 이것은 다음 분류를 제안한다:"
#. Tag: para
#, no-c-format
msgid "indexed collections"
msgstr "인덱싱 된 콜렉션들"
#. Tag: para
#, no-c-format
msgid "sets"
msgstr "set들"
#. Tag: para
#, no-c-format
msgid "bags"
msgstr "bag들"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"All indexed collections (maps, lists, and arrays) have a primary key "
"consisting of the <literal><key> and <index>"
"literal> columns. In this case, collection updates are extremely efficient. "
"The primary key can be efficiently indexed and a particular row can be "
"efficiently located when Hibernate tries to update or delete it."
msgstr ""
"모든 인덱싱된 콜렉션들(map들, list들, array들)은 <literal><key>"
"literal>와 <literal><index> 컬럼들로 이루어진 프라이머리 키"
"를 갖는다. 이 경우에 콜렉션 업데이트들은 대개 극히 효율적이다 - Hibernate가 "
"그것을 업데이트나 삭제를 시도할 때 프라이머리 키는 효율적으로 인덱싱될 수 있"
"고 특정 행은 효율적으로 위치지워질 수 있다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Sets have a primary key consisting of <literal><key> and "
"element columns. This can be less efficient for some types of collection "
"element, particularly composite elements or large text or binary fields, as "
"the database may not be able to index a complex primary key as efficiently. "
"However, for one-to-many or many-to-many associations, particularly in the "
"case of synthetic identifiers, it is likely to be just as efficient. If you "
"want <literal>SchemaExport to actually create the primary key of a "
"<literal><set>, you must declare all columns as not-"
"null=\"true\"</literal>."
msgstr ""
"Set들은 <literal><key>와 요소 컬럼들로 구성된 프라이머리 키"
"를 갖는다. 이것은 몇몇 유형의 콜렉션 요소, 특히 composite 요소들 또는 대형 텍"
"스트 또는 바이너리 필드들에 대해 덜 효율적일 수 있다; 데이터베이스는 복잡한 "
"프라이머리 키를 효율적으로 인덱싱하는 것이 불가능할 수도 있다. 반면에 one to "
"many 또는 many to many 연관들의 경우, 특히 합성 식별자들의 경우에는 효율적일 "
"수 있을 것 같다.(부수-노트: 만일 당신이 당신을 위한 <literal><set>"
"literal>의 프라이머리 키를 실제로 생성시키기 위해 <literal>SchemaExport"
"literal>를 원한다면 당신은 모든 컬럼들을 <literal>not-null=\"true\""
"로 선언해야 한다.)"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal><idbag> mappings define a surrogate key, so they "
"are efficient to update. In fact, they are the best case."
msgstr ""
"<literal><idbag> 매핑들은 대용 키를 정의하여서, 그것들은 항"
"상 업데이트에 매우 효율적이다. 사실, 그것들은 최상의 경우이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Bags are the worst case since they permit duplicate element values and, as "
"they have no index column, no primary key can be defined. Hibernate has no "
"way of distinguishing between duplicate rows. Hibernate resolves this "
"problem by completely removing in a single <literal>DELETE and "
"recreating the collection whenever it changes. This can be inefficient."
msgstr ""
"Bag들은 가장 나쁜 경우이다. 왜냐하면 하나의 bag은 중복 요소 값들을 허용하고 "
"인덱스 컬럼을 갖지 않기 때문에, 프라이머리 키가 정의될 수 없다. Hibernate는 "
"중복 행들 사이를 구분 짓는 방법을 갖고 있지 않다. Hibernate는 그것이 변경될 "
"때마다 (한 개의 DELETE로) 콜렉션을 완전하게 제거하고 다시 생성시킴으로써 이 "
"문제를 해결한다. 이것은 매우 비효율적이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"For a one-to-many association, the \"primary key\" may not be the physical "
"primary key of the database table. Even in this case, the above "
"classification is still useful. It reflects how Hibernate \"locates\" "
"individual rows of the collection."
msgstr ""
"one-to-many 연관의 경우, \"프라이머리 키\"는 데이터베이스 테이블의 물리적인 "
"프라이머리 키가 아닐 수도 있지만- 이 경우에서도 위의 분류는 여전히 유용하다. "
"(그것은 여전히 Hibernate가 콜렉션의 개별 행들을 어떻게 \"위치지우는\"지를 반"
"영한다.)"
#. Tag: title
#, no-c-format
msgid ""
"Lists, maps, idbags and sets are the most efficient collections to update"
msgstr "List, map, idbag, set들은 update에 가장 효율적인 콜렉션들이다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"From the discussion above, it should be clear that indexed collections and "
"sets allow the most efficient operation in terms of adding, removing and "
"updating elements."
msgstr ""
"위의 논의에서, 인덱싱된 콜렉션들과 (대개) set들이 요소들을 추가하고, 제거하"
"고 업데이트함에 있어 가장 효율적인 오퍼레이션을 허용해준다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"There is, arguably, one more advantage that indexed collections have over "
"sets for many-to-many associations or collections of values. Because of the "
"structure of a <literal>Set, Hibernate does not UPDATE"
"literal> a row when an element is \"changed\". Changes to a <literal>Set"
"literal> always work via <literal>INSERT and DELETE"
"literal> of individual rows. Once again, this consideration does not apply "
"to one-to-many associations."
msgstr ""
"아마 인덱싱 된 콜렉션들이 many to many 연관들을 위한 또는 값들을 가진 콜렉션"
"들을 위한 set들에 대해 갖고 있는 하나 이상의 장점들이 존재한다. "
"<literal>Set의 구조 때문에, Hibernate는 요소가 \"변경\"될 때 행을 "
"<literal>UPDATE 하지 않는다. Set에 대한 변경들"
"은 항상 (개별 행들에 대한) <literal>INSERT와 DELETE"
"literal>를 통해 동작한다. 다시 이 검토는 one to many 연관들에 적용되지 않는"
"다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"After observing that arrays cannot be lazy, you can conclude that lists, "
"maps and idbags are the most performant (non-inverse) collection types, with "
"sets not far behind. You can expect sets to be the most common kind of "
"collection in Hibernate applications. This is because the \"set\" semantics "
"are most natural in the relational model."
msgstr ""
"배열들이 lazy 될 수 없음을 관찰 한 후에, 우리는 list들, map들, 그리고 idbag들"
"이 단독이 아닌 set들을 가진 가장 퍼포먼스가 좋은(non-inverse) 콜렉션 타입들임"
"을 결론 지을 것이다. Set들은 Hibernate 어플리케이션들에서 가장 공통된 종류의 "
"콜렉션이 될 것이라 예상된다. 이것은 \"set\" 의미가 관계형 모형에서 가장 고유"
"한 것이기 때문이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"However, in well-designed Hibernate domain models, most collections are in "
"fact one-to-many associations with <literal>inverse=\"true\". For "
"these associations, the update is handled by the many-to-one end of the "
"association, and so considerations of collection update performance simply "
"do not apply."
msgstr ""
"하지만, 잘 설계된 Hibernate 도메인 모형들에서, 우리는 대개 대부분의 콜렉션들"
"이 사실 <literal>inverse=\"true\"를 가진 one-to-many 연관들임을 보"
"게 된다. 이들 연관들의 경우, 업데이트는 연관의 many-to-one 엔드에 의해 처리되"
"고, 따라서 콜렉션 업데이트 퍼포먼스에 대한 검토들은 단순히 적용되지 않는다."
#. Tag: title
#, no-c-format
msgid "Bags and lists are the most efficient inverse collections"
msgstr "Bag들과 list들은 가장 효율적인 inverse 콜렉션들이다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"There is a particular case, however, in which bags, and also lists, are much "
"more performant than sets. For a collection with <literal>inverse=\"true\""
"literal>, the standard bidirectional one-to-many relationship idiom, for "
"example, we can add elements to a bag or list without needing to initialize "
"(fetch) the bag elements. This is because, unlike a <literal>set, "
"<literal>Collection.add() or Collection.addAll()"
"literal> must always return true for a bag or <literal>List. This "
"can make the following common code much faster:"
msgstr ""
"단지 당신이 영원히 bag들을 버리기 전에, bag들(과 또한 list들)이 set들보다 훨"
"씬 더 성능이 좋은 특별한 경우들이 존재한다. <literal>inverse=\"true\""
"literal>를 가진 콜렉션들(예를 들어, 표준 양방향 one-to-many 관계 특질)의 경"
"우, 우리는 bag 요소들을 초기화(페치) 시킬 필요 없이 bag 또는 list에 요소들을 "
"추가시킬 수 있다! 이것은 <literal>Collection.add() 또는 "
"<literal>Collection.addAll()이 (Set과는 달리) 항"
"상 bag 또는 <literal>List에 대해 true를 반환해야하기 때문이다. 이것"
"은 훨씬 다음 공통적인 코드를 더 빠르게 만들 수 있다."
#. Tag: title
#, no-c-format
msgid "One shot delete"
msgstr "원 샷 delete"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Deleting collection elements one by one can sometimes be extremely "
"inefficient. Hibernate knows not to do that in the case of an newly-empty "
"collection (if you called <literal>list.clear(), for example). In "
"this case, Hibernate will issue a single <literal>DELETE."
msgstr ""
"종종 콜렉션 요소들을 하나씩 삭제하는 것은 극히 비효율적일 수 있다! Hibernate"
"는 완전하게 바보가 아니어서, 그것은 새로운 공백의 콜렉션의 경우(예를 들어 당"
"신이 <literal>list.clear()를 호출했을 경우)에 그것을 행하지 않을 것"
"임을 알고 있다. 이 경우에, Hibernate는 하나의 <literal>DELETE 명령"
"을 내릴 것이고 우리는 모두 행했다!"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Suppose you added a single element to a collection of size twenty and then "
"remove two elements. Hibernate will issue one <literal>INSERT "
"statement and two <literal>DELETE statements, unless the "
"collection is a bag. This is certainly desirable."
msgstr ""
"우리가 길이 20인 하나의 콜렉션에 한 개의 요소를 추가하고 그런 다음 두 개의 요"
"소들을 제거한다고 가정하자. Hibernate는 (콜렉션이 bag가 아닌 한) 한 개의 "
"<literal>INSERT 문장과 두 개의 DELETE 문장을 명"
"령 내릴 것이다. 이것은 확실히 마음에 든다."
#. Tag: para
#, no-c-format
msgid ""
"However, suppose that we remove eighteen elements, leaving two and then add "
"thee new elements. There are two possible ways to proceed"
msgstr ""
"하지만, 우리가 두 개의 요소들을 남겨둔채 18 개의 요소들을 제거하고 나서 세 개"
"의 새로운 요소들을 추가한다고 가정하자. 두 가지 가능한 처리 방법들이 존재한"
"다."
#. Tag: para
#, no-c-format
msgid "delete eighteen rows one by one and then insert three rows"
msgstr "하나씩 열 여덟 개의 행들을 삭제한 다음에 세 개의 행들을 삽입시킨다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"remove the whole collection in one SQL <literal>DELETE and insert "
"all five current elements one by one"
msgstr ""
"(한 개의 SQL <literal>DELETE로)전체 콜렉션을 삭제하고 모든 다섯개"
"의 현재 요소들을 (하나씩) insert 시킨다"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate cannot know that the second option is probably quicker. It would "
"probably be undesirable for Hibernate to be that intuitive as such behavior "
"might confuse database triggers, etc."
msgstr ""
"Hibernate는 두 번째 옵션이 아마 이 경우에 더 빠르다는 점을 알 만큼 충분히 영"
"리하지 않다.(그리고 Hibernate가 그렇게 영리해지는 것을 희망 하는 것은 가능하"
"지 않을 것이다; 그런 특징은 데이터베이스 트리거들 등을 혼동스럽게 할 수도 있"
"다.)"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Fortunately, you can force this behavior (i.e. the second strategy) at any "
"time by discarding (i.e. dereferencing) the original collection and "
"returning a newly instantiated collection with all the current elements."
msgstr ""
"다행히, 당신은 원래의 콜렉션을 폐기시키고(예를 들어 참조 해제하고) 모든 현재 "
"요소들을 가진 새로이 초기화된 콜렉션을 반환함으로써 아무때든지 이 특징을 강제"
"시킬 수 있다. 이것은 시간이 흐름에 따라 매우 유용하고 강력해질 수 있다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"One-shot-delete does not apply to collections mapped <literal>inverse=\"true"
"\"</literal>."
msgstr ""
"물론 단 한번의 삭제(one-shot-delete)는 <literal>inverse=\"true\"로 "
"매핑된 콜렉션들에 적용되지 않는다."
#. Tag: title
#, no-c-format
msgid "Monitoring performance"
msgstr "퍼포먼스 모니터링하기"
#. Tag: para
#, no-c-format
msgid ""
"Optimization is not much use without monitoring and access to performance "
"numbers. Hibernate provides a full range of figures about its internal "
"operations. Statistics in Hibernate are available per "
"<literal>SessionFactory."
msgstr ""
"최적화는 퍼포먼스 관련 숫자들에 대한 모니터링과 접근 없이는 많이 사용되지 않"
"는다. Hibernate는 그것의 내부적인 오퍼레이션들에 대한 전체 영역의 특징들을 제"
"공한다. Hibernate에서 Statistics는 <literal>SessionFactory에 대해 "
"이용 가능하다."
#. Tag: title
#, no-c-format
msgid "Monitoring a SessionFactory"
msgstr "SessionFactory 모니터링 하기"
#. Tag: para
#, no-c-format
msgid ""
"You can access <literal>SessionFactory metrics in two ways. Your "
"first option is to call <literal>sessionFactory.getStatistics() "
"and read or display the <literal>Statistics yourself."
msgstr ""
"당신은 두 가지 방법들로 <literal>SessionFactory metrics에 접근할 "
"수 있다. 당신의 첫 번째 옵션은 <literal>sessionFactory.getStatistics()"
"literal>를 호출하고 당신 스스로 <literal>Statistics를 읽거나 디스플"
"레이 하는 것이다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate can also use JMX to publish metrics if you enable the "
"<literal>StatisticsService MBean. You can enable a single MBean "
"for all your <literal>SessionFactory or one per factory. See the "
"following code for minimalistic configuration examples:"
msgstr ""
"만일 당신이 <literal>StatisticsService MBean을 이용 가능하도록 할 "
"경우 Hibernate는 또한 metrics를 발표하는데 JMX를 사용할 수 있다. 당신은 모든 "
"당신의<literal>SessionFactory에 대해 한 개의 MBean 또는 팩토리 당 "
"한 개를 이용 가능하게 할 수 있다. 최소한의 구성 예제들은 다음 코드를 보라:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can activate and deactivate the monitoring for a "
"<literal>SessionFactory:"
msgstr ""
"당신은 <literal>SessionFactory에 대한 모니터링을 (비)활성화 시킬 "
"수 있다"
#. Tag: para
#, no-c-format
msgid ""
"at configuration time, set <literal>hibernate.generate_statistics "
"to <literal>false"
msgstr ""
"구성 시 : <literal>hibernate.generate_statistics, 디폴트는 "
"<literal>false"
#. Tag: para
#, no-c-format
msgid ""
"at runtime: <literal>sf.getStatistics().setStatisticsEnabled(true) "
"or <literal>hibernateStatsBean.setStatisticsEnabled(true)"
msgstr ""
"실행 시 : <literal>sf.getStatistics().setStatisticsEnabled(true) 또"
"는 <literal>hibernateStatsBean.setStatisticsEnabled(true)"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Statistics can be reset programmatically using the <literal>clear()"
"literal> method. A summary can be sent to a logger (info level) using the "
"<literal>logSummary() method."
msgstr ""
"Statistics(통계량들)은 <literal>clear() 메소드를 사용하여 프로그래"
"밍 방식으로 재설정 될 수 있다. 요약은 <literal>logSummary() 메소드"
"를 사용하여 logger(info 레벨)에게 전송될 수 있다."
#. Tag: title
#, no-c-format
msgid "Metrics"
msgstr "Metrics"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate provides a number of metrics, from basic information to more "
"specialized information that is only relevant in certain scenarios. All "
"available counters are described in the <literal>Statistics "
"interface API, in three categories:"
msgstr ""
"Hibernate는 매우 기본적인 것에서부터 어떤 시나리오들에만 관련된 전문 정보에 "
"이르는 많은 metrics를 제공한다. 모든 이용 가능한 카운터들은 "
"<literal>Statistics interface API에서 3개의 카테고리로 설명되어 있"
"다:"
#. Tag: para
#, no-c-format
msgid ""
"Metrics related to the general <literal>Session usage, such as "
"number of open sessions, retrieved JDBC connections, etc."
msgstr ""
"열려진 세션들의 개수, 검색된 JDBC 커넥션들의 개수 등과 같은 일반적인 "
"<literal>Session 사용에 관련된 metrics."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Metrics related to the entities, collections, queries, and caches as a whole "
"(aka global metrics)."
msgstr ""
"전체적으로 엔티티들, 콜렉션들, 질의들, 그리고 캐시들에 관련된 metrics(전역 "
"metrics로 알려져 있음),"
#. Tag: para
#, no-c-format
msgid ""
"Detailed metrics related to a particular entity, collection, query or cache "
"region."
msgstr "특정한 엔티티, 콜렉션, 질의 또는 캐시 영역에 관련된 상세 metrics."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"For example, you can check the cache hit, miss, and put ratio of entities, "
"collections and queries, and the average time a query needs. Be aware that "
"the number of milliseconds is subject to approximation in Java. Hibernate is "
"tied to the JVM precision and on some platforms this might only be accurate "
"to 10 seconds."
msgstr ""
"예를 들어 당신은 엔티티, 콜렉션, 질의들의 캐시 성공율 및 실패율, put(역자 "
"주, 캐시 시도, putt) 비율, 콜렉션들과 질의들, 그리고 평균 질의 요구 시간 등"
"을 찾을 수 있다. 수 밀리초들가 자바에서 근사치에 종속됨을 의식하라. Hibernate"
"는 JVM 정밀도에 묶여 있고, 몇몇 플랫폼들에서 이것은 심지어 약 10초가 될 수도 "
"있다."
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Simple getters are used to access the global metrics (i.e. not tied to a "
"particular entity, collection, cache region, etc.). You can access the "
"metrics of a particular entity, collection or cache region through its name, "
"and through its HQL or SQL representation for queries. Please refer to the "
"<literal>Statistics, EntityStatistics, "
"<literal>CollectionStatistics, "
"<literal>SecondLevelCacheStatistics, and QueryStatistics"
"literal> API Javadoc for more information. The following code is a simple "
"example:"
msgstr ""
"간단한 getter들은 (예를 들어 특정 엔티티, 콜렉션, 캐시 영역에 묶이지 않은) 전"
"역 metrics에 접근하는데 사용된다. 당신은 그것(특정 엔티티, 콜렉션, 또는 캐시 "
"영역)의 이름을 통해, 그리고 질의들에 대한 그것의 HQL 또는 SQL 표현을 통해 특"
"정 엔티티, 콜렉션, 또는 캐시 영역의 metrics에 접근할수 있다. 추가 정보는 "
"<literal>Statistics, EntityStatistics, "
"<literal>CollectionStatistics, "
"<literal>SecondLevelCacheStatistics, 그리고 "
"<literal>QueryStatistics를 참조하라. 다음 코드는 간단한 예제를 보여"
"준다:"
#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can work on all entities, collections, queries and region caches, by "
"retrieving the list of names of entities, collections, queries and region "
"caches using the following methods: <literal>getQueries(), "
"<literal>getEntityNames(), getCollectionRoleNames()"
"literal>, and <literal>getSecondLevelCacheRegionNames()."
msgstr ""
"모든 엔티티들, 콜렉션들, 콜렉션들,질의들 그리고 영역 캐시들에 대해 작업하기 "
"위해, 당신은 다음 메소드들로서 엔티티들, 콜렉션들, 질의들, 그리고 영역 캐시들"
"에 대한 이름들의 목록을 검색할 수 있다: <literal>getQueries(), "
"<literal>getEntityNames(), getCollectionRoleNames()"
"literal>, 그리고 <literal>getSecondLevelCacheRegionNames()."
#, fuzzy
#~ msgid ""
#~ "This setting creates two new cache regions: one holding cached query "
#~ "result sets (<literal>org.hibernate.cache.StandardQueryCache), "
#~ "the other holding timestamps of the most recent updates to queryable "
#~ "tables (<literal>org.hibernate.cache.UpdateTimestampsCache). "
#~ "Note that the query cache does not cache the state of the actual entities "
#~ "in the result set; it caches only identifier values and results of value "
#~ "type. The query cache should always be used in conjunction with the "
#~ "second-level cache."
#~ msgstr ""
#~ "이 설정은 두 개의 새로운 캐시 영역들 - 캐시된 질의 결과 셋들을 보관하는 "
#~ "것 (<literal>org.hibernate.cache.StandardQueryCache), 질의 가능"
#~ "한 테이블들에 대한 가장 최신 업데이트들에 대한 timestamp들을 보관하는 다"
#~ "른 것 (<literal>org.hibernate.cache.UpdateTimestampsCache)-의 생"
#~ "성을 강제한다 . 질의 캐시는 결과 셋 내에 실제 엔티티들의 상태를 캐시시키"
#~ "지 않음을 노트하라; 그것은 오직 식별자 값들과 값 타입의 결과들 만을 캐시시"
#~ "킨다. 따라서 질의 캐시는 항상 second-level 캐시와 함께 사용되어야 한다."
#~ msgid ""
#~ "where <literal>CatImpl implements the interface Cat"
#~ "literal> and <literal>DomesticCatImpl implements the interface "
#~ "<literal>DomesticCat. Then proxies for instances of "
#~ "<literal>Cat and DomesticCat may be returned "
#~ "by <literal>load() or iterate(). (Note that "
#~ "<literal>list() does not usually return proxies.)"
#~ msgstr ""
#~ "여기서 <literal>CatImpl은 Cat 인터페이스를 구"
#~ "현하고 <literal>DomesticCatImpl은 DomesticCat"
#~ "literal> 인터페이스를 구현한다. 그때 <literal>Cat과 "
#~ "<literal>DomesticCat의 인스턴스들에 대한 프락시들은 "
#~ "<literal>load() 또는 iterate()에 의해 반환될 "
#~ "수 있다. (<literal>list()가 대개 프락시들을 반환하지 않음을 노트"
#~ "하라.)"
#~ msgid ""
#~ "We've already spent quite some time talking about collections. In this "
#~ "section we will highlight a couple more issues about how collections "
#~ "behave at runtime."
#~ msgstr ""
#~ "우리는이미 콜렉션들에 관해 얘기하는데 꽤 많은 시간을 소요했다. 이 절에서 "
#~ "우리는 콜렉션들이 실행 시에 어떻게 행위하는지에 관한 한 쌍의 쟁점들을 조명"
#~ "할 것이다."
#~ msgid ""
#~ "TODO: This doesn't make sense: In the first case, we retrieve and use the "
#~ "MBean directly. In the second one, we must give the JNDI name in which "
#~ "the session factory is held before using it. Use "
#~ "<literal>hibernateStatsBean.setSessionFactoryJNDIName(\"my/JNDI/Name\")"
#~ "literal>"
#~ msgstr ""
#~ "TODO: 이것은 의미가 없다: 첫번째 경우에, 우리는 직접 MBean을 검색하고 사용"
#~ "한다. 두 번째 경우에 우리는 JNDI 이름을 사용하기 전에 세션 팩토리가 보관하"
#~ "고 있는 JNDI 이름을 부여해야 한다. <literal>hibernateStatsBean."
#~ "setSessionFactoryJNDIName(\"my/JNDI/Name\")</literal>을 사용하라."
Other Hibernate examples (source code examples)
Here is a short list of links related to this Hibernate performance.po source code file:
|