Hibernate example source code file (transactions.po)

This example Hibernate source code file (transactions.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.

Java - Hibernate tags/keywords

a, cmt, ejb, hibernate, hibernate, in, jdbc, jta, jta, tag, tag, the, the, this

The Hibernate transactions.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
#, fuzzy, no-c-format
msgid "Transactions and Concurrency"
msgstr "트랜잭션들과 동시성"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The most important point about Hibernate and concurrency control is that it "
"is easy to understand. Hibernate directly uses JDBC connections and JTA "
"resources without adding any additional locking behavior. It is recommended "
"that you spend some time with the JDBC, ANSI, and transaction isolation "
"specification of your database management system."
msgstr ""
"Hibernate와 동시성 제어에 대한 가장 중요한 점은 이해하기가 매우 쉽다는 점이"
"다. Hibernate는 어떤 추가적인 잠금 행위 없이 JDBC 커넥션들과 JTA 리소스들을 "
"직접 사용한다. 우리는 당신의 데이터베이스 관리 시스템의 JDBC, ANSI, 그리고 트"
"랜잭션 격리 명세에 약간의 시간을 할애할 것을 매우 권장한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate does not lock objects in memory. Your application can expect the "
"behavior as defined by the isolation level of your database transactions. "
"Through <literal>Session, which is also a transaction-scoped "
"cache, Hibernate provides repeatable reads for lookup by identifier and "
"entity queries and not reporting queries that return scalar values."
msgstr ""
"Hibernate는 메모리 내에서 객체들을 잠그지 않는다. 당신의 어플리케이션은 격리 "
"레벨에 의해 정의된 대로 행위를 기대할 수 있다. 또한 transaction-영역의 캐시"
"인 <literal>Session 덕분에, Hibernate는 (스칼라 값들을 반환하는 질"
"의들을 보고하지 않는) 식별자와 엔티티 질의들에 의한 룩업을 위해 반복 가능한 "
"읽기를 제공한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In addition to versioning for automatic optimistic concurrency control, "
"Hibernate also offers, using the <literal>SELECT FOR UPDATE "
"syntax, a (minor) API for pessimistic locking of rows. Optimistic "
"concurrency control and this API are discussed later in this chapter."
msgstr ""
"자동적인 optimistic 동시성 제어를 위한 버전화에 덧붙여, Hibernate는 또한 "
"<literal>SELECT FOR UPDATE 구문을 사용하여 행들에 대한 pessimistic "
"잠금을 위한 하나의 (마이너)API를 제공한다. optimistic 동시성 제어와 이 API는 "
"이 장의 뒷부분에서 논의된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The discussion of concurrency control in Hibernate begins with the "
"granularity of <literal>Configuration, SessionFactorySession, as well as database transactions "
"and long conversations."
msgstr ""
"우리는 <literal>Configuration, SessionFactory, "
"<literal>Session, 알갱이를 가진 Hibernate에서의 동시성 제어 뿐만 아"
"니라 데이터베이스 트랜잭션과 장기간에 걸친 (컴퓨터와의)대화들에 대한 논의를 "
"시작한다."

#. Tag: title
#, no-c-format
msgid "Session and transaction scopes"
msgstr "세션 영역과 트랜잭션 영역"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A <literal>SessionFactory is an expensive-to-create, threadsafe "
"object, intended to be shared by all application threads. It is created "
"once, usually on application startup, from a <literal>Configuration는 모든 어플리케이션 쓰레드들에 의해 공유되"
"도록 고안된 생성에 비용이 드는, 쓰레드안전(threadsafe) 객체이다. 그것은 대개 "
"어플리케이션 시작 시에 <literal>Configuration 인스턴스로부터 한번 "
"생성된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A <literal>Session is an inexpensive, non-threadsafe object that "
"should be used once and then discarded for: a single request, a conversation "
"or a single unit of work. A <literal>Session will not obtain a "
"JDBC <literal>Connection, or a Datasource, "
"unless it is needed. It will not consume any resources until used."
msgstr ""
"<literal>Session은 하나의 요청, 하나의 대화 , 하나의 작업 단위를 위"
"해 한번만 사용되고 나서 폐기될 예정인, 비용이 들지 않는, 쓰레드 안전하지 않"
"은 객체이다. <literal>Session은 커넥션이 필요하지 않으면 하나의 "
"JDBC <literal>Connection(또는 Datasource)를 얻"
"지 않을 것이므로, 사용될 때까지 리소스들을 소비하지 않는다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In order to reduce lock contention in the database, a database transaction "
"has to be as short as possible. Long database transactions will prevent your "
"application from scaling to a highly concurrent load. It is not recommended "
"that you hold a database transaction open during user think time until the "
"unit of work is complete."
msgstr ""
"이 그림을 완성하기 위해 당신은 또한 데이터베이스 트랜재션들에 대해 생각해야 "
"한다. 데이터베이스 트랜잭션은 데이터베이스에서 잠금 다툼을 줄이기 위해 가능"
"한 짧아야 한다. 긴 데이터베이스 트랜잭션들은 당신의 어플리케이션이 고도의 동"
"시성 로드로의 가용성을 높이는 것을 방해할 것이다. 그러므로 사용자가 생각하는 "
"시간 동안 단위 작업이 완료될 때까지 데이터베이스 트랜잭션을 열려진채로 소유하"
"는 것은 대개 결코 좋은 설계는 아니다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"What is the scope of a unit of work? Can a single Hibernate "
"<literal>Session span several database transactions, or is this a "
"one-to-one relationship of scopes? When should you open and close a "
"<literal>Session and how do you demarcate the database transaction "
"boundaries? These questions are addressed in the following sections."
msgstr ""
"하나의 작업 단위의 영역은 무엇인가? 하나의 Hibernate <literal>Session을 열고 닫는가 "
"그리고 당신은 데이터베이스 트랜잭션 경계들을 어떻게 한정하는가?"

#. Tag: title
#, no-c-format
msgid "Unit of work"
msgstr "작업 단위"

#. Tag: para
#, no-c-format
msgid ""
"First, let's define a unit of work. A unit of work is a design pattern "
"described by Martin Fowler as <quote> [maintaining] a list of objects "
"affected by a business transaction and coordinates the writing out of "
"changes and the resolution of concurrency problems. </quote>PoEAA antipattern: do "
"not open and close a <literal>Session for every simple database "
"call in a single thread. The same is true for database transactions. "
"Database calls in an application are made using a planned sequence; they are "
"grouped into atomic units of work. This also means that auto-commit after "
"every single SQL statement is useless in an application as this mode is "
"intended for ad-hoc SQL console work. Hibernate disables, or expects the "
"application server to disable, auto-commit mode immediately. Database "
"transactions are never optional. All communication with a database has to "
"occur inside a transaction. Auto-commit behavior for reading data should be "
"avoided, as many small transactions are unlikely to perform better than one "
"clearly defined unit of work. The latter is also more maintainable and "
"extensible."
msgstr ""
"첫번째로, <emphasis>session-per-operation anti-패턴을 사용하지 말"
"라. 즉, 단일 쓰레드 내에서 모든 간단한 데이터베이스 호출에 대해 "
"<literal>Session을 열고 닫지 말라! 물론 같은 것이 데이터베이스 트랜"
"잭션들에 대해서도 참이다. 어플리케이션 내의 데이터베이스 호출들은 계획된 순서"
"를사용하여 행해지며, 그것들은 원자 작업 단위 속으로 그룹지워진다. (이것은 또"
"한 모든 하나의 SQL 문장 뒤의 auto-commit(자동-커밋)이 어플리케이션 내에서 무"
"용지물임을 의미하고, 이 모드가 SQL 콘솔 작업을 돕도록 고안되었음을 노트하라. "
"Hibernate는 의미하고, 이 모드는 Hibernate는 즉시 자동-커밋 모드를 사용 불가능"
"하게 하거나, 어플리케이션 서버가 그렇게 행하고, 즉시 자동-커밋시키는 것을 사"
"용불가능하게 하거나 ,그렇게 행하는 것을 기대한다.) 데이터베이스 트랜잭션들은 "
"결코 옵션이 아니며, 하나의 데이터베이스와의 모든 통신은 당신이 데이터를 읽든 "
"쓰단간에 상관없이 하나의 트랜잭션 내에서 발생해야 한다. 설명하였듯이, 데이터 "
"읽기를 위한 auto-commit 특징을 피해야 할 것이며, 많은 작은 트랜잭션들은 하나"
"의 명료하게 정의된 작업 단위보다 더 좋게 수행될 것 같지 않다. 후자가 또한 훨"
"씬 더 유지가능하고 확장적이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The most common pattern in a multi-user client/server application is "
"<emphasis>session-per-request. In this model, a request from the "
"client is sent to the server, where the Hibernate persistence layer runs. A "
"new Hibernate <literal>Session is opened, and all database "
"operations are executed in this unit of work. On completion of the work, and "
"once the response for the client has been prepared, the session is flushed "
"and closed. Use a single database transaction to serve the clients request, "
"starting and committing it when you open and close the <literal>Session이다. 이 모형에서, 클라이언트로부터"
"의 요청은 (Hibernate 영속 계층이 실행되는) 서버로 전송되고, 새로운 Hibernate "
"<literal>Session이 열려지고, 모든 데이터베이스 오퍼레이션들이 이 작"
"업 단위 내에서 실행된다. 일단 그 작업이 완료되었다면(그리고 클라이언트에 대"
"한 응답이 준비되었다면), 그 세션은 flush 되고 닫혀진다. 당신은 또한 당신이 "
"<literal>Session을 열고 닫을 때 그것을 시작하고 커밋시켜서 클라이언"
"트 요청에 서비스하는데 한 개의 데이터베이스 트랜잭션을 사용하게 될 것이다. "
"둘 사이의 관계는 일대일 대응이고 이 모형은 많은 어플리케이션들에서 완전하게 "
"적합하다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The challenge lies in the implementation. Hibernate provides built-in "
"management of the \"current session\" to simplify this pattern. Start a "
"transaction when a server request has to be processed, and end the "
"transaction before the response is sent to the client. Common solutions are "
"<literal>ServletFilter, AOP interceptor with a pointcut on the "
"service methods, or a proxy/interception container. An EJB container is a "
"standardized way to implement cross-cutting aspects such as transaction "
"demarcation on EJB session beans, declaratively with CMT. If you use "
"programmatic transaction demarcation, for ease of use and code portability "
"use the Hibernate <literal>Transaction API shown later in this "
"chapter."
msgstr ""
"난제는 구현에 놓여있다: Hibernate는 이 패턴을 단순화 시키기 위해 \"현재 세션"
"\"에 관한 미리 빌드된 관리를 제공한다. 당신이 행해야할 모든 것은 서버 요청이 "
"처리되어야 할 때 트랜잭션을 시작하고, 그 응답이 클라이언트로 전송되기 전에 트"
"랜잭션을 끝내는 것이다. 당신은 당신이 좋아하는 임의의 방법으로 이것을 행할 "
"수 있으며, 공통된 해결책들은 서비스 메소드들 상의 첨단, 또는 하나의 프락시/인"
"터셉션 컨테이너를 가진 APO 인터셉터인, <literal>ServletFilter이다. "
"하나의 EJB 컨테이너는 CMT의 경우에 선언적으로 EJB session beans 상에 트랜잭"
"션 경계구분과 같은 동시 대조 측면들을 구현하는 표준 방법이다. 만일 당신이 프"
"로그램 상의 트랜잭션 경계구분을 사용하고자 결정한다면, 사용의 용이성과 코드 "
"이식성을 위해 이 장의 뒷 부분에서 보여진 Hibernate <literal>Transaction. "
"You will always get a <literal>Session scoped to the current "
"database transaction. This has to be configured for either resource-local or "
"JTA environments, see <xref linkend=\"architecture-current-session\" />."
msgstr ""
"당신의 어플리케이션 코드는 어디서든 필요할 때 종종 <literal>sessionFactory."
"getCurrentSession()</literal>을 간단히 호출함으로써 요청을 처리할 \"현재 세션"
"\"에 접근할 수 있다. 당신은 현재 데이터베이스 트랜잭션으로 영역화된 하나의 "
"<literal>Session을 항상 얻게 될 것이다. 이것은 resource-local 환경 "
"또는 JTA 환경에 대해 구성되어야 하며, <xref linkend=\"architecture-current-"
"session\"/>을 보라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can extend the scope of a <literal>Session and database "
"transaction until the \"view has been rendered\". This is especially useful "
"in servlet applications that utilize a separate rendering phase after the "
"request has been processed. Extending the database transaction until view "
"rendering, is achieved by implementing your own interceptor. However, this "
"will be difficult if you rely on EJBs with container-managed transactions. A "
"transaction will be completed when an EJB method returns, before rendering "
"of any view can start. See the Hibernate website and forum for tips and "
"examples relating to this <emphasis>Open Session in View pattern."
msgstr ""
"때때로 \"뷰가 렌더링될 때까지\" 하나의 <literal>Session 과 데이터베"
"이스 트랜잭션의 영역을 확장시키는 것이 편리하다. 이것은 요청이 처리된 후에 하"
"나의 별도의 렌더링 단계를 활용하는 서블릿 어플리케이션들에서 특히 유용하다. "
"뷰 렌더링이 완료될 때까지 데이터베이스 트랜잭션을 확장하는 것은 당신이 당신 "
"자신의 인터셉터를 구현하는 경우에 행하기가 쉽다. 하지만 만일 당신이 컨테이너"
"에 의해 관리되는 트랜잭션들을 가진 EJB들에 의존할 경우에, 하나의 EJB 메소드"
"가 반환될 때 임의의 뷰 렌더링이 시작될 수 있기 전에 하나의 트랜잭션이 완료되"
"기 때문에, 행하는 것이 쉽지 않다. 이 <emphasis>Open Session in View and database transaction. "
"The user is free to modify the objects."
msgstr ""
"대화상자의 첫 번째 화면이 열리고, 사용자에게 보여진 데이터는 특정 "
"<literal>Session과 데이터베이스 트랜잭션 속에 로드되었다. 사용자가 "
"객체들을 변경시키는 것이 자유롭다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The user clicks \"Save\" after 5 minutes and expects their modifications to "
"be made persistent. The user also expects that they were the only person "
"editing this information and that no conflicting modification has occurred."
msgstr ""
"사용자는 5분 후에 \"저장\"을 클릭하고 그의 변경들이 영속화 되기를 기대한다; "
"그는 또한 그가 이 정보를 편집하는 유일한 개인이고 변경 충돌이 발생하지 않기"
"를 기대한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"From the point of view of the user, we call this unit of work a long-running "
"<emphasis>conversation or application transaction어플리케이션 트랜잭션)이라고 명명한다. "
"당신이 당신의 어플리케이션에서 이것을 어떻게 구현할 수 있는 많은 방법들이 존"
"재한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A first naive implementation might keep the <literal>Session and "
"database transaction open during user think time, with locks held in the "
"database to prevent concurrent modification and to guarantee isolation and "
"atomicity. This is an anti-pattern, since lock contention would not allow "
"the application to scale with the number of concurrent users."
msgstr ""
"첫 번째 naive 구현은 동시성 변경을 방지하고, 격리와 atomicity(원자 단위성)을 "
"보장하기 위해 데이터베이스에 의해 소유된 잠금으로 사용자가 생각하는동안 "
"<literal>Session과 데이터베이스 트랜잭션을 유지할 수도 있다. 이것"
"은 물론 anti-패턴이다. 왜냐하면 잠금 다툼은 어플리케이션이 동시 사용자들의 가"
"용 숫자를 높이는 것을 허용하지 않을 것이기 때문이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You have to use several database transactions to implement the conversation. "
"In this case, maintaining isolation of business processes becomes the "
"partial responsibility of the application tier. A single conversation "
"usually spans several database transactions. It will be atomic if only one "
"of these database transactions (the last one) stores the updated data. All "
"others simply read data (for example, in a wizard-style dialog spanning "
"several request/response cycles). This is easier to implement than it might "
"sound, especially if you utilize some of Hibernate's features:"
msgstr ""
"명료하게, 우리는 대화(<emphasis>어플리케이션 트랜잭션)를 구현하는"
"데 몇몇 데이터베이스 트랜잭션들을 사용해야 한다. 이 경우에, 비지니스 프로세스"
"들의 격리를 유지하는 것은 어플리케이션 티어의 부분적인 책임이 된다. 단일 대화"
"는 대개 여러 개의 데이터베이스 트랜잭션들에 걸친다. 그것은 이들 데이터베이스 "
"트랜잭션들 중 오직 한 개(마지막 트랜잭션)가 업데이트된 데이터를 저장하고, 모"
"든 다른 트랜잭션들이 단순히 데이터를 읽는 (예를 들면, 몇몇 요청/응답 주기에 "
"걸치는 마법사 스타일의 대화 상자에서) 경우에만 원자단위가 될 것이다. 특히 당"
"신이 Hibernate의 특징들을 사용할 경우에 , 이것은 들리는 것보다 구현하기가 더 "
"쉽다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Automatic Versioning: Hibernate can perform automatic "
"optimistic concurrency control for you. It can automatically detect if a "
"concurrent modification occurred during user think time. Check for this at "
"the end of the conversation."
msgstr ""
"<emphasis>자동적인 버전화 - Hibernate는 당신을 위해 자동적인 "
"optimistic 동시성 제어를 행할 수 있고, 그것은 사용자가 생각하는 시간 동안 동"
"시적인 변경이 발생했는지를 자동적으로 검출할 수 있다. 대개 우리는 오직 대화"
"의 끝에서 체크한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Detached Objects: if you decide to use the "
"<emphasis>session-per-request pattern, all loaded instances will "
"be in the detached state during user think time. Hibernate allows you to "
"reattach the objects and persist the modifications. The pattern is called "
"<emphasis>session-per-request-with-detached-objects. Automatic "
"versioning is used to isolate concurrent modifications."
msgstr ""
"<emphasis>Detached 객체들 - 만일 당신이 이미 논의된 "
"<emphasis>session-per-request 패턴을 사용하고자 결정하는 경우, 모"
"든 로드된 인스턴스들은 사용자가 생각하는 시간 동안 detached 상태에 있을 것이"
"다. Hibernate는 그 객체들을 재첨부시키고 변경들을 영속화 시키는 것을 허용해주"
"며, 그 패턴은 <emphasis>session-per-request-with-detached-objects(detached-객"
"체들을 가진 요청 당 세션)</emphasis>으로 명명된다. 자동적인 버전화는 동시성 "
"변경들을 격리시키는데 사용된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<emphasis>Extended (or Long) Session: the Hibernate "
"<literal>Session can be disconnected from the underlying JDBC "
"connection after the database transaction has been committed and reconnected "
"when a new client request occurs. This pattern is known as <emphasis>session-"
"per-conversation</emphasis> and makes even reattachment unnecessary. "
"Automatic versioning is used to isolate concurrent modifications and the "
"<literal>Session will not be allowed to be flushed automatically, "
"but explicitly."
msgstr ""
"<emphasis>확장된 (또는 Long) Session - Hibernate "
"<emphasis>Session은 데이터베이스 트랜잭션이 커밋된 후에 기본 JDBC "
"커넥션이 연결 해제될 수도 있고, 새로운 클라이언트 요청이 발생할 때 다시 연결"
"될 수 있다. 이 패턴은 <emphasis>session-per-conversation(대화 당 세션)은 자동적으로 "
"flush되는 것이 허용되지 않지만 명시적으로 flush되는 것은 허용된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Both <emphasis>session-per-request-with-detached-objects and "
"<emphasis>session-per-conversation have advantages and "
"disadvantages. These disadvantages are discussed later in this chapter in "
"the context of optimistic concurrency control."
msgstr ""
"<emphasis>session-per-request-with-detached-objectsê³¼ "
"<emphasis>session-per-conversation 양자는 장점들과 단점들을 갖는"
"데, 우리는 이 장의 뒷 부분에서 optimistic 동시성 제어 단락에서 그것들을 논의"
"한다."

#. Tag: title
#, no-c-format
msgid "Considering object identity"
msgstr "객체 identity 고려하기"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"An application can concurrently access the same persistent state in two "
"different <literal>Sessions. However, an instance of a persistent "
"class is never shared between two <literal>Session instances. It "
"is for this reason that there are two different notions of identity:"
msgstr ""
"어플리케이션은 두 개의 다른 <literal>Session들 내에 있는 동일한 영"
"속 상태에 동시에 접근할 수도 있다. 하지만 영속 클래스의 인스턴스는 두 개의 "
"<literal>Session 인스턴스들 사이에 결코 공유되지 않는다. 그러므로 "
"identity에 대한 두 개의 다른 개념들이 존재한다:"

#. Tag: term
#, no-c-format
msgid "Database Identity"
msgstr "데이터베이스 Identity"

#. Tag: para
#, fuzzy, no-c-format
msgid "<literal>foo.getId().equals( bar.getId() )"
msgstr "foo.getId().equals( bar.getId() )"

#. Tag: term
#, no-c-format
msgid "JVM Identity"
msgstr "JVM Identity"

#. Tag: para
#, no-c-format
msgid "<literal>foo==bar"
msgstr ""

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"For objects attached to a <emphasis>particular SessionSession), the two "
"notions are equivalent and JVM identity for database identity is guaranteed "
"by Hibernate. While the application might concurrently access the \"same"
"\" (persistent identity) business object in two different sessions, the two "
"instances will actually be \"different\" (JVM identity). Conflicts are "
"resolved using an optimistic approach and automatic versioning at flush/"
"commit time."
msgstr ""
"그때 (예를 들어 <literal>Session 영역에서) 특정Session에 첨부된 객체들의 경우 두 개의 개념들은 "
"동등한 것이고, 데이터베이스 identity에 대한 JVM identity가 Hibernate에 의해 "
"보장된다. 하지만, 어플리케이션이 두 개의 다른 세션들에서 \"동일한\" (영속 "
"identity) 비지니스 객체에 동시에 접근하는 동안, 두 개의 인스턴스들은 실제로 "
"\"다르다\"(JVM identity). 충돌들은 flush/커밋 시에 (자동적인 버전화)를 사용하"
"여, optimistic 접근법을 사용하여 해결된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"This approach leaves Hibernate and the database to worry about concurrency. "
"It also provides the best scalability, since guaranteeing identity in single-"
"threaded units of work means that it does not need expensive locking or "
"other means of synchronization. The application does not need to synchronize "
"on any business object, as long as it maintains a single thread per "
"<literal>Session. Within a Session the "
"application can safely use <literal>== to compare objects."
msgstr ""
"이 접근법은 Hibernate와 데이터베이스가 동시성에 대해 걱정하지 않도록 해준다; "
"그것은 또한 최상의 scalability를 제공한다. 왜냐하면 단일 쓰레드-작업 단위 내"
"에서 identity 보장은 단지 비용이 드는 잠금이나 다른 동기화 수단들을 필요로 하"
"지 않기 때문이다. 어플리케이션은 그것이 <literal>Session 당 단일 쓰"
"레드를 강제하는 한, 어떤 비지니스 객체에 대해 결코 동기화 시킬 필요가 없다. "
"하나의 <literal>Session 내에서 어플리케이션은 객체들을 비교하는데 "
"<literal>==를 안전하게 사용할 수가 있다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"However, an application that uses <literal>== outside of a "
"<literal>Session might produce unexpected results. This might "
"occur even in some unexpected places. For example, if you put two detached "
"instances into the same <literal>Set, both might have the same "
"database identity (i.e., they represent the same row). JVM identity, "
"however, is by definition not guaranteed for instances in a detached state. "
"The developer has to override the <literal>equals() and "
"<literal>hashCode() methods in persistent classes and implement "
"their own notion of object equality. There is one caveat: never use the "
"database identifier to implement equality. Use a business key that is a "
"combination of unique, usually immutable, attributes. The database "
"identifier will change if a transient object is made persistent. If the "
"transient instance (usually together with detached instances) is held in a "
"<literal>Set, changing the hashcode breaks the contract of the "
"<literal>Set. Attributes for business keys do not have to be as "
"stable as database primary keys; you only have to guarantee stability as "
"long as the objects are in the same <literal>Set. See the "
"Hibernate website for a more thorough discussion of this issue. Please note "
"that this is not a Hibernate issue, but simply how Java object identity and "
"equality has to be implemented."
msgstr ""
"하지만, 하나의 <literal>Session 외부에서 ==를 사"
"용하는 어플리케이션은 예기치 않은 결과들을 보게 될 수도 있다. 이것은 어떤 예"
"기치 않은 장소들에서, 예를 들어 당신이 두 개의 detached 인스턴스들을 동일한 "
"<literal>Set 내에 집어넣을 경우에 발생할 수도 있다. 둘 다 동일한 데"
"이터베이스 identity를 가질 수 있지만 (예를 들어 그것들은 동일한 행을 표현한"
"다), JVM identity는 정의 상 detached 상태에 있는 인스턴스들을 보장하지 않는"
"다. 개발자는 영속 클래스들내에 <literal>equals() 메소드와 "
"<literal>hashCode() 메소드를 오버라이드 시켜야 하고 객체 equality"
"에 대한 그 자신의 개념을 구현해야 한다. 하나의 경고가 존재한다: equality를 구"
"현하는데 데이터베이스 identifier를 결코 사용하지 말고, 하나의 비지니스 키, 유"
"일한, 대개 불변인 속성들의 조합을 사용하라. 데이터베이스 식별자는 만일 "
"transient 객체가 영속화되는 경우에 변경될 것이다. 만일 transient 인스턴스가"
"(대개 detached 인스턴스들과 함께) <literal>Set 내에 보관되는 경우"
"에, hashcode 변경은 <literal>Set의 계약을 파기시킨다. 비지니스 키들"
"에 대한 속성들은 데이터베이스 프라이머리 키들 만큼 안정적이어서는 안되며, 당"
"신은 오직 객체들이 동일한 <literal>Set 내에 있는 한에서 안정성을 보"
"장해야만 한다. 이 쟁점에 관한 논의에 대한 더 많은 것을 Hibernate 웹 사이트를 "
"보라. 또한 이것이 Hibernate 쟁점이 아니며, 단지 자바 객체 identity와 equality"
"가 구현되어야 하는 방법임을 노트하라."

#. Tag: title
#, no-c-format
msgid "Common issues"
msgstr "공통된 쟁점들"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Do not use the anti-patterns <emphasis>session-per-user-session "
"or <emphasis>session-per-application (there are, however, rare "
"exceptions to this rule). Some of the following issues might also arise "
"within the recommended patterns, so ensure that you understand the "
"implications before making a design decision:"
msgstr ""
"안티-패턴들 <emphasis>session-per-user-session 또는 "
"<emphasis>session-per-application을 결코 사용하지 말라(물론 이 규"
"칙에 대한 드문 예외상황들이 존재한다). 다음 쟁점들 중 몇몇이 또한 권장되는 패"
"턴들로 나타날 수 있음을 노트하고, 당신이 설계 결정을 내리기 전에 내포된 의미"
"들을 확실히 이해하라:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A <literal>Session is not thread-safe. Things that work "
"concurrently, like HTTP requests, session beans, or Swing workers, will "
"cause race conditions if a <literal>Session instance is shared. If "
"you keep your Hibernate <literal>Session in your "
"<literal>HttpSession (this is discussed later in the chapter), you "
"should consider synchronizing access to your Http session. Otherwise, a user "
"that clicks reload fast enough can use the same <literal>Session "
"in two concurrently running threads."
msgstr ""
"<literal>Session은 쓰레드-안전하지 않다. HTTP 요청들, 세션 빈즈, 또"
"는 Swing worker들처럼 동시에 작업하는 것으로 가정되는 것들은 하나의 "
"<literal>Session 인스턴스가 공유될 경우에 경쟁 조건들을 발생시킬 것"
"이다. 만일 당신이 당신의 <literal>HttpSession 내에 Hibernate "
"<literal>Session을 유지시키는 경우(나중에 논의됨), 당신은 당신의 "
"Http 세션에 대한 접근을 동기화 시키는 것을 고려해야 한다. 그 밖의 경우, 충분"
"히 빠르게 reload를 클릭하는 사용자는 두 개의 동시적으로 실행되는 쓰레드들 내"
"에서 동일한 <literal>Session을 사용할 수도 있다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"An exception thrown by Hibernate means you have to rollback your database "
"transaction and close the <literal>Session immediately (this is "
"discussed in more detail later in the chapter). If your <literal>Session을 닫아야 함을 의미한다(나중에 상세"
"히 논의됨). 만일 당신의 <literal>Session이 어플리케이션에 바인드 되"
"어 있는 경우, 당신은 어플리케이션을 중지시켜야 한다. 데이터베이스 트랜잭션 롤"
"백은 당신의 비지니스 객체들을 그것들이 트랜잭션의 시작 시에 머물렀던 상태로 "
"되돌리지는 않는다. 이것은 데이터베이스 상태와 비지니스 객체들이 동기화를 벗어"
"남을 의미한다. 대개 이것은 문제가 아니다. 왜냐하면 예외상황들은 회복가능한 것"
"이 아니고 당신이 어떻게든 롤백 후에 시작해야 하기 때문이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>Session caches every object that is in a persistent "
"state (watched and checked for dirty state by Hibernate). If you keep it "
"open for a long time or simply load too much data, it will grow endlessly "
"until you get an OutOfMemoryException. One solution is to call <literal>clear"
"()</literal> and evict() to manage the Session open for the duration of a user session "
"also means a higher probability of stale data."
msgstr ""
"<literal>Session은 (Hibernate에 의해 dirty 상태로 관찰되었거나 체크"
"된) 영속 상태에 있는 모든 객체를 캐시 시킨다. 이것은 당신이 오랜 시간 동안 "
"<literal>Session을 열어둔 채로 유지하거나 단순하게 너무 많은 데이터"
"를 로드시킬 경우에, 당신이 OutOfMemoryException을 얻기 전까지, 그것이 끝없이 "
"성장한다는 점을 의미한다. 이것에 대한 하나의 해결책은 <literal>Sessionclear()와 evict()을 열려진 채로 유지하는 것은 또한 실효성이 떨어진 "
"데이터에 대한 높은 확률을 의미한다."

#. Tag: title
#, no-c-format
msgid "Database transaction demarcation"
msgstr "데이터베이스 트랜잭션 경계 설정"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Database, or system, transaction boundaries are always necessary. No "
"communication with the database can occur outside of a database transaction "
"(this seems to confuse many developers who are used to the auto-commit "
"mode). Always use clear transaction boundaries, even for read-only "
"operations. Depending on your isolation level and database capabilities this "
"might not be required, but there is no downside if you always demarcate "
"transactions explicitly. Certainly, a single database transaction is going "
"to perform better than many small transactions, even for reading data."
msgstr ""
"데이터베이스 (또는 시스템) 트랜잭션 경계들은 항상 필수적이다. 데이터베이스와"
"의 통신은 데이터베이스 트랜잭션의 외부에서 발생할 수 없다(이것은 자동-커밋 모"
"드로 사용되는 많은 개발자들에게는 혼동스러워 보인다). 항상 심지어 읽기 전용 "
"오퍼레이션들에 대해서도 명료한 트랜잭션 경계들을 사용하라. 당신의 격리 레벨"
"과 데이터베이스 가용성들에 따라, 이것은 필요하지 않을 수 있지만, 만일 당신이 "
"항상 트랜잭션들을 명시적으로 경계 설정할 경우에는 하강하는 결점들이 존재하지 "
"않는다. 확실히, 하나의 데이터베이스 트랜잭션은 심지어 데이터 읽기조차도 많은 "
"작은 트랜잭션들의 경우보다는 더 좋게 수행될 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A Hibernate application can run in non-managed (i.e., standalone, simple "
"Web- or Swing applications) and managed J2EE environments. In a non-managed "
"environment, Hibernate is usually responsible for its own database "
"connection pool. The application developer has to manually set transaction "
"boundaries (begin, commit, or rollback database transactions) themselves. A "
"managed environment usually provides container-managed transactions (CMT), "
"with the transaction assembly defined declaratively (in deployment "
"descriptors of EJB session beans, for example). Programmatic transaction "
"demarcation is then no longer necessary."
msgstr ""
"Hibernate 어플리케이션은 관리되지 않는 환경(예를 들면. 스탠드얼론, 간단히 웹 "
"어플리케이션들 또는 Swing 어플리케이션들)과 관리되는 J2EE 환경에서 실행될 수 "
"있다. 관리되지 않는 환경에서, Hibernate는 대개 그것 자신의 데이터베이스 커넥"
"션 풀에 대한 책임이 있다. 어플리케이션 개발자는 트랜잭션 경계들을 손수 설정해"
"야 한다. 달리 말해, 개발자 스스로 데이터베이스 트랜잭션들을 시작하고, 커밋시"
"키거나 롤백시켜야 한다. 관리되는 환경은 대개 예를 들어 EJB 세션 빈즈의 배치 "
"디스크립터 속에 선언적으로 정의된 트랜잭션 어셈블리를 가진, 컨테이너에 의해-"
"관리되는 트랜잭션들(CMT)을 제공한다. 그때 프로그램 상의 트랜잭션 경계 설정은 "
"더 이상 필요하지 않다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"However, it is often desirable to keep your persistence layer portable "
"between non-managed resource-local environments, and systems that can rely "
"on JTA but use BMT instead of CMT. In both cases use programmatic "
"transaction demarcation. Hibernate offers a wrapper API called "
"<literal>Transaction that translates into the native transaction "
"system of your deployment environment. This API is actually optional, but we "
"strongly encourage its use unless you are in a CMT session bean."
msgstr ""
"하지만, CMT 대신 BMT를 사용하는 JTA에 의존할 수 있는 시스템들, 그리고 관리되"
"지 않는 resource-local 환경들 사이에서 당신의 영속 계층에 이식성을 유지시키"
"는 것이 자주 희망된다. 두 경우들에서 당신은 프로그램 상의 트랜잭션 경계설정"
"을 사용할 것이다. Hibernate는 당신의 배치 환경의 고유한 트랜잭션 시스템 속으"
"로 변환되는 <literal>Transaction이라 명명되는 wrapper API 를 제공한"
"다. 이 API는 실제로 옵션이지만 우리는 당신이 CMT session bean 속에 있지 않는 "
"한 그것의 사용을 강력하게 권장한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Ending a <literal>Session usually involves four distinct phases:"
msgstr ""
"대개 <literal>Session 종료는 네 개의 구분되는 단계들을 수반한다:"

#. Tag: para
#, no-c-format
msgid "flush the session"
msgstr "세션을 flush 시킨다"

#. Tag: para
#, no-c-format
msgid "commit the transaction"
msgstr "트랜잭션을 커밋 시킨다"

#. Tag: para
#, no-c-format
msgid "close the session"
msgstr "세션을 닫는다"

#. Tag: para
#, no-c-format
msgid "handle exceptions"
msgstr "예외상황들을 처리한다"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"We discussed Flushing the session earlier, so we will now have a closer look "
"at transaction demarcation and exception handling in both managed and non-"
"managed environments."
msgstr ""
"세션을 flush 시키는 것은 앞서 논의되었고, 우리는 이제 관리되는 환경과 관리되"
"지 않는 환경 양자에서 트랜잭션 경계 설정과 예외상황을 더 자세히 살펴볼 것이"
"다."

#. Tag: title
#, no-c-format
msgid "Non-managed environment"
msgstr "관리되지 않는 환경"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If a Hibernate persistence layer runs in a non-managed environment, database "
"connections are usually handled by simple (i.e., non-DataSource) connection "
"pools from which Hibernate obtains connections as needed. The session/"
"transaction handling idiom looks like this:"
msgstr ""
"만일 Hibernate 영속 계층이 관리되지 않는(non-managed) 환경에서 실행될 경우, "
"데이터베이스 커넥션들은 대개 Hibernate가 필요로할 때 커넥션들을 획득하는 간단"
"한 (예를 들면 DataSource가 아닌) 커넥션 풀(pool)들로부터 처리된다. session/"
"transaction 처리 관용구는 다음과 같다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You do not have to <literal>flush() the Session "
"explicitly: the call to <literal>commit() automatically triggers "
"the synchronization depending on the <link linkend=\"objectstate-flushing"
"\">FlushMode</link> for the session. A call to close() "
"marks the end of a session. The main implication of <literal>close()을 명시적으로 flush() 하"
"지 말아야 한다 - <literal>commit()에 대한 호출은 (그 세션에 대한 "
"<xref linkend=\"objectstate-flushing\">FlushMode에 따라)자동적으로 동"
"기화를 트리거시킨다. <literal>close()에 대한 호출은 세션의 끝을 마"
"크한다. <literal>close()의 주된 구현은 JDBC 커넥션이 그 세션에 의"
"해 포기될 것이라는 점이다. 이 Java 코드는 관리되지 않는 환경과 JTA 환경 양자"
"에서 이식성이 있고 실행된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"As outlined earlier, a much more flexible solution is Hibernate's built-in "
"\"current session\" context management:"
msgstr ""
"보다 더 유연한 해결책은 앞서 설명했듯이 Hibernate의 미리 빌드되어 있는 \"현"
"재 세션\" 컨텍스트 관리이다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You will not see these code snippets in a regular application; fatal "
"(system) exceptions should always be caught at the \"top\". In other words, "
"the code that executes Hibernate calls in the persistence layer, and the "
"code that handles <literal>RuntimeException (and usually can only "
"clean up and exit), are in different layers. The current context management "
"by Hibernate can significantly simplify this design by accessing a "
"<literal>SessionFactory. Exception handling is discussed later in "
"this chapter."
msgstr ""
"당신은 통상의 어플리케이션에서 비지니스 코드 속에 이 관용구를 결코 보지 않을 "
"것이다; 치명적인(시스템) 예외상황들은 항상 \"상단\"에서 잡혀야 한다. 달리 말"
"해, (영속 계층에서) Hibernate 호출들을 실행시키는 코드와 "
"<literal>RuntimeException을 처리하(고 대개 오직 제거하고 빠져나갈 "
"수 있는) 코드는 다른 계층들 속에 있다. Hibernate에 의한 현재 컨텍스트 관리는 "
"이 설계를 현격하게 단순화시켜서, 당신이 필요로 하는 모든 것은 "
"<literal>SessionFactory에 대한 접근이다.예외상황 처리는 이 장의 뒷"
"부분에서 논의된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You should select <literal>org.hibernate.transaction.JDBCTransactionFactory"
"\"thread\"</literal> as your hibernate."
"current_session_context_class</literal>."
msgstr ""
"당신은 (디폴트인) <literal>org.hibernate.transaction.JDBCTransactionFactoryhibernate."
"current_session_context_class</literal>를 선택해야 함을 노트하라."

#. Tag: title
#, no-c-format
msgid "Using JTA"
msgstr "JTA 사용하기"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If your persistence layer runs in an application server (for example, behind "
"EJB session beans), every datasource connection obtained by Hibernate will "
"automatically be part of the global JTA transaction. You can also install a "
"standalone JTA implementation and use it without EJB. Hibernate offers two "
"strategies for JTA integration."
msgstr ""
"만일 당신의 영속 계층이 어플리케이션 서버에서(예를 들어, EJB 세션 빈즈 이면에"
"서) 실행될 경우, Hibernate에 의해 획득된 모든 데이터소스 커넥션은 자동적으로 "
"전역 JTA 트랜잭션의 부분일 것이다. 당신은 또한 스탠드얼론 JTA 구현을 설치할 "
"수 있고 EJB 없이 그것을 사용할 수 있다. Hibernate는 JTA 통합을 위한 두 개의 "
"방도들을 제공한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If you use bean-managed transactions (BMT), Hibernate will tell the "
"application server to start and end a BMT transaction if you use the "
"<literal>Transaction API. The transaction management code is "
"identical to the non-managed environment."
msgstr ""
"만일 당신이 bean-managed transactions(BMT)를 사용할 경우 Hibernate는 당신이 "
"<literal>Transaction API를 사용할 경우에 BMT 트랜잭션을 시작하고 종"
"료하도록 어플리케이션 서버에게 알려줄 것이다. 따라서 트랜잭션 관리 코드는 "
"non-managed 환경과 동일하다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If you want to use a transaction-bound <literal>Session, that is, "
"the <literal>getCurrentSession() functionality for easy context "
"propagation, use the JTA <literal>UserTransaction API directly:"
msgstr ""
"만일 당신이 트랜잭션에 묶인 <literal>Session, 즉 쉬운 컨텍스트 보급"
"을 위한 <literal>getCurrentSession() 기능을 사용하고자 원할 경우, "
"당신은 JTA <literal>UserTransaction API를 직접 사용해야 할 것이다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"With CMT, transaction demarcation is completed in session bean deployment "
"descriptors, not programmatically. The code is reduced to:"
msgstr ""
"CMT의 경우, 트랜잭션 관할[경계 설정]은 프로그램 상이 아닌, session bean 배치 "
"디스크립터들 속에서 행해진다. 그러므로 코드는 다음으로 감소된다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In a CMT/EJB, even rollback happens automatically. An unhandled "
"<literal>RuntimeException thrown by a session bean method tells "
"the container to set the global transaction to rollback. <emphasis>You do "
"not need to use the Hibernate <literal>Transaction API at all with "
"BMT or CMT, and you get automatic propagation of the \"current\" Session "
"bound to the transaction.</emphasis>"
msgstr ""
"왜냐하면 하나의 세션 빈 메소드에 의해 던져진 처리되지 않은 "
"<literal>RuntimeException이 글로벌 트랜잭션을 rollback으로 설정하도"
"록 컨테이너에게 알려주기 때문에, CMT/EJB에서조차 롤백은 자동적으로 발생된다. "
"<emphasis>이것은 당신이 BMT 이든 CMT이든 모두에서 Hibernate "
"<literal>Transaction API를 사용할 필요가 없으며, 당신은 그 트랜잭션"
"에 묶인 \"현재\" Session의 자동적인 보급(propagation)을 얻게 됨을 의미한다.</"
"emphasis>"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"When configuring Hibernate's transaction factory, choose <literal>org."
"hibernate.transaction.JTATransactionFactory</literal> if you use JTA "
"directly (BMT), and <literal>org.hibernate.transaction."
"CMTTransactionFactory</literal> in a CMT session bean. Remember to also set "
"<literal>hibernate.transaction.manager_lookup_class. Ensure that "
"your <literal>hibernate.current_session_context_class is either "
"unset (backwards compatibility), or is set to <literal>\"jta\"."
msgstr ""
"당신이 Hibernate의 트랜잭션 팩토리를 구성할 때, 당신이 JTA를 직접 사용할 경우"
"(BMT) 당신은 <literal>org.hibernate.transaction.JTATransactionFactoryorg.hibernate."
"transaction.CMTTransactionFactory</literal>를 선택해야 함을 노트하라. 또한 "
"<literal>org.hibernate.transaction.manager_lookup_class를 설정하는 "
"것을 염두에 두라. 게다가 반드시 당신의 <literal>hibernate."
"current_session_context_class</literal>이 설정되지 않도록 하거나(역호환성), "
"또는 <literal>\"jta\"로 설정되도록 하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>getCurrentSession() operation has one downside in a "
"JTA environment. There is one caveat to the use of <literal>after_statement or "
"<literal>Iterator instances returned by scroll()iterate(). You must "
"release the underlying database cursor by calling <literal>ScrollableResults."
"close()</literal> or Hibernate.close(Iterator) explicitly "
"from a <literal>finally block. Most applications can easily avoid "
"using <literal>scroll() or iterate() from the "
"JTA or CMT code.)"
msgstr ""
"<literal>getCurrentSession() 오퍼레이션들은 JTA 환경에서 한 가지 단"
"점을 갖고 있다. 디폴트로 사용되는, <literal>after_statement 커넥션 "
"해제 모드 사용에 대한 하나의 보류 통보가 존재한다. JTA 명세서의 어리석은 제한"
"으로 인해, Hibernate가 <literal>scroll() 또는 iterate()ScrollableResultsIterator 인스턴스들을 자동적으로 제거하는 것"
"이 불가능하다. 당신은 <literal>finally 블록 내에서 명시적으로 "
"<literal>ScrollableResults.close() 또는 Hibernate.close"
"(Iterator)</literal>를 호출하여 기본 데이터베이스 커서를 해제시켜"
"야 한다</emphasis>.(물론 대부분의 어플리케이션들은 JTA 또는 CMT 코드에서 "
"<literal>scroll()이나 iterate()를 사용하는 것을 "
"쉽게 피할 수 있다.)"

#. Tag: title
#, no-c-format
msgid "Exception handling"
msgstr "예외상황 처리"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If the <literal>Session throws an exception, including any "
"<literal>SQLException, immediately rollback the database "
"transaction, call <literal>Session.close() and discard the "
"<literal>Session instance. Certain methods of Sessionnot leave the session in a consistent "
"state. No exception thrown by Hibernate can be treated as recoverable. "
"Ensure that the <literal>Session will be closed by calling "
"<literal>close() in a finally block."
msgstr ""
"만일<literal>Session이 (어떤 SQLException을 포함"
"하는) 예외상황을 던질 경우, 당신은 데이터베이스 트랜잭션을 즉시 롤백시키고, "
"<literal>Session.close()를 호출하고 Session 인스"
"턴스를 폐기시켜야한다. <literal>Session의 어떤 메소드들은 그 세션"
"을 일관된 상태로 남겨두지 <emphasis>않을 것이다. Hibernate에 의해 "
"던져진 예외상황은 복구가능한 것으로 취급될 수 없다. 그 <literal>Sessionfinally 블록 내에서 close()"
"를 호출하여 닫혀지도록 확실히 하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>HibernateException, which wraps most of the errors "
"that can occur in a Hibernate persistence layer, is an unchecked exception. "
"It was not in older versions of Hibernate. In our opinion, we should not "
"force the application developer to catch an unrecoverable exception at a low "
"layer. In most systems, unchecked and fatal exceptions are handled in one of "
"the first frames of the method call stack (i.e., in higher layers) and "
"either an error message is presented to the application user or some other "
"appropriate action is taken. Note that Hibernate might also throw other "
"unchecked exceptions that are not a <literal>HibernateException. "
"These are not recoverable and appropriate action should be taken."
msgstr ""
"Hibernate 영속 계층에서 발생할 수 있는 대부분의 오류들을 포장하는, "
"<literal>HibernateException은 체크되지 않은 예외상황이다(그것은 "
"Hibernate의 이전 버전에는 없었다). 우리의 의견으로, 우리는 낮은 계층에서 복구"
"불가능한 예외상황을 붙잡도록 어플리케이션 개발자에게 강제하지 않을 것이다. 대"
"부분의 시스템들에서, 체크되지 않은 치명적인 예외상황들은 (예를 들어, 더 높은 "
"계층에서) 메소드 호출 스택의 첫 번째 프레임들 중 하나 속에서 처리되고, 한 개"
"의 오류 메시지가 어플리케이션 사용자에게 표시된다(또는 어떤 다른 적절한 액션"
"이 취해진다). Hibernate는 또한 <literal>HibernateException이 아닌, "
"다른 체크되지 않은 예외상황들을 던질 수도 있음을 노트하라. 다시 이것들은 복구"
"가능하지 않고 적절한 액션이 취해져야 한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate wraps <literal>SQLExceptions thrown while interacting "
"with the database in a <literal>JDBCException. In fact, Hibernate "
"will attempt to convert the exception into a more meaningful subclass of "
"<literal>JDBCException. The underlying SQLExceptionJDBCException.getCause()SQLException into an "
"appropriate <literal>JDBCException subclass using the "
"<literal>SQLExceptionConverter attached to the "
"<literal>SessionFactory. By default, the "
"<literal>SQLExceptionConverter is defined by the configured "
"dialect. However, it is also possible to plug in a custom implementation. "
"See the javadocs for the <literal>SQLExceptionConverterFactory "
"class for details. The standard <literal>JDBCException subtypes "
"are:"
msgstr ""
"Hibernate는 데이터베이스와 상호작용하는 동안에 던져진 <literal>SQLExceptionJDBCException 속에 포장한다. 사실, "
"Hibernate는 그 예외상황을 <literal>JDBCException의 보다 의미있는 서"
"브클래스로 변환하려고 시도할 것이다. 기본 <literal>SQLException은 "
"<literal>JDBCException.getCause()를 통해 항상 이용 가능하다. "
"Hibernate는<literal>SessionFactory에 첨부된 "
"<literal>SQLExceptionConverter를 사용하여 SQLExceptionJDBCException 서브클래스로 변환시"
"킨다. 디폴트로 <literal>SQLExceptionConverter는 구성된 dialect에 의"
"해 정의된다; 하지만 맞춤 구현 속에 플러그인 시키는 것이 또한 가능하다(상세한 "
"것은 <literal>SQLExceptionConverterFactory 클래스에 관한 javadocs"
"를 보라). 표준 <literal>JDBCException 서브타입은 다음과 같다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>JDBCConnectionException: indicates an error with the "
"underlying JDBC communication."
msgstr ""
"<literal>JDBCConnectionException - 기본 JDBC 통신에 대한 오류를 나"
"타낸다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>SQLGrammarException: indicates a grammar or syntax "
"problem with the issued SQL."
msgstr ""
"<literal>SQLGrammarException - 생겨난 SQL에 대한 문법 또는 구문 문"
"제점을 나타낸다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>ConstraintViolationException: indicates some form of "
"integrity constraint violation."
msgstr ""
"<literal>ConstraintViolationException - 무결성 제약 위반에 관한 어"
"떤 형식을 나타낸다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>LockAcquisitionException: indicates an error acquiring a "
"lock level necessary to perform the requested operation."
msgstr ""
"<literal>LockAcquisitionException - 요청된 오퍼레이션을 실행하는데 "
"필수적인 잠금 레벨을 획득하는 오류를 나타낸다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>GenericJDBCException: a generic exception which did not "
"fall into any of the other categories."
msgstr ""
"<literal>GenericJDBCException - 다른 카테고리들 중 어떤 것으로 분류"
"되지 않았던 일반적인 예외상황."

#. Tag: title
#, no-c-format
msgid "Transaction timeout"
msgstr "트랜잭션 타임아웃"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"An important feature provided by a managed environment like EJB, that is "
"never provided for non-managed code, is transaction timeout. Transaction "
"timeouts ensure that no misbehaving transaction can indefinitely tie up "
"resources while returning no response to the user. Outside a managed (JTA) "
"environment, Hibernate cannot fully provide this functionality. However, "
"Hibernate can at least control data access operations, ensuring that "
"database level deadlocks and queries with huge result sets are limited by a "
"defined timeout. In a managed environment, Hibernate can delegate "
"transaction timeout to JTA. This functionality is abstracted by the "
"Hibernate <literal>Transaction object."
msgstr ""
"관리되지 않는 코드에 대해서는 결코 제공되지 않는 EJB와 같이 관리되는 환경에 "
"의해 제공되는 한 가지 극히 중요한 특징은 트랜잭션 타임아웃이다. 트랜잭션 타임"
"아웃은 사용자에게 응답을 반환하지 않는 동안에 무례한 행동을 행하는 트랜잭션"
"이 자원들을 무한정 묶어둘 수 없음을 보증해준다. 관리되는 (JTA) 환경 외부에"
"서, Hibernate는 이 기능을 온전하게 제공할 수 없다. 하지만 Hibernate는 데이터"
"베이스 레벨 데드락들과 거대한 결과 셋들을 가진 질의들이 정의된 타임아웃에 의"
"해 제약되는 것을 보장함으로써 최소한 데이터 접근 오퍼레이션들을 제어할 수 있"
"다. 관리되는 환경에서, Hibernate는 트랜잭션 타임아웃을 JTA에게 위임시킬 수 있"
"다. 이 기능은 Hibernate <literal>Transaction 객체에 의해 추상화 된"
"다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>setTimeout() cannot be called in a CMT bean, where "
"transaction timeouts must be defined declaratively."
msgstr ""
"<literal>setTimeout()은 CMT bean 내에서 호출도리 수 없음을 노트하"
"라. 여기서 트랜잭션 타임아웃들은 선언적으로 정의되어야 한다."

#. Tag: title
#, no-c-format
msgid "Optimistic concurrency control"
msgstr "Optimistic 동시성 제어"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The only approach that is consistent with high concurrency and high "
"scalability, is optimistic concurrency control with versioning. Version "
"checking uses version numbers, or timestamps, to detect conflicting updates "
"and to prevent lost updates. Hibernate provides three possible approaches to "
"writing application code that uses optimistic concurrency. The use cases we "
"discuss are in the context of long conversations, but version checking also "
"has the benefit of preventing lost updates in single database transactions."
msgstr ""
"고도의 동시성과 고도의 가용성을 일치시키는 유일한 접근법은 버전화를 가진 "
"optimistic동시성 제어이다. 버전 체킹은 업데이트 충돌을 검출하기 위해(그리고 "
"업데이트 손실을 방지하기 위해) 버전 번호들 또는 timestamp들을 사용한다. "
"Hibernate는 optimistic 동시성을 사용하는 어플리케이션 코드 작성에 세 가지 가"
"능한 접근법들을 제공한다. 우리가 보여주는 쓰임새들은 장시간의 대화의 상황 속"
"에 있지만, 버전 체킹 또한 단일 데이터베이스 트랜잭션들에서 업데이트 손실을 방"
"지하는 이점을 갖고 있다."

#. Tag: title
#, no-c-format
msgid "Application version checking"
msgstr "어플리케이션 버전 체킹"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In an implementation without much help from Hibernate, each interaction with "
"the database occurs in a new <literal>Session and the developer is "
"responsible for reloading all persistent instances from the database before "
"manipulating them. The application is forced to carry out its own version "
"checking to ensure conversation transaction isolation. This approach is the "
"least efficient in terms of database access. It is the approach most similar "
"to entity EJBs."
msgstr ""
"하나의 구현에서 Hibernate로부터 많은 도움이 없이, 데이터베이스에 대한 각각의 "
"상호작용은 새로운 <literal>Session 내에서 일어나고, 개발자는 영속 "
"인스턴스들을 처리하기 전에 데이터베이스로부터 모든 영속 인스턴스들을 다시 로"
"드시킬 책임이 있다. 이 접근법은 대화 트랜잭션을 확실히 격리시키기 위해 그것 "
"자신의 버전 체킹을 수행하도록 어플리케이션에게 강제시킨다."

#. Tag: para
#, no-c-format
msgid ""
"The <literal>version property is mapped using <"
"version></literal>, and Hibernate will automatically increment it during "
"flush if the entity is dirty."
msgstr ""
"version 프로퍼티는 <literal><version>을 사용하여 매핑되고, "
"Hibernate는 만일 엔티티가 dirty일 경우 flush 동안에 그것을 자동적으로 증가시"
"킬 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"If you are operating in a low-data-concurrency environment, and do not "
"require version checking, you can use this approach and skip the version "
"check. In this case, <emphasis>last commit wins is the default "
"strategy for long conversations. Be aware that this might confuse the users "
"of the application, as they might experience lost updates without error "
"messages or a chance to merge conflicting changes."
msgstr ""
"물론, 당신이 낮은 데이터 동시성 환경에서 작업하고 있고 버전 체킹을 필요로 하"
"지 않을 경우에, 당신은 이 접근법을 사용할 수 도 있고 단지 버전 체크를 생략할 "
"수도 있다. 그 경우에, <emphasis>마지막의 커밋 성공은 당신의 장시간"
"의 대화에 대한 디폴트 방도가 될 것이다. 이것이 어플리케이션의 사용자들을 혼동"
"시킬 수 있음을 염두에 두라. 왜냐하면 사용자들은 오류 메시지들 또는 충돌 변경"
"들을 병합시킬 기회 없이 업데이트들 손실을 겪을 수도 있기 때문이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Manual version checking is only feasible in trivial circumstances and not "
"practical for most applications. Often not only single instances, but "
"complete graphs of modified objects, have to be checked. Hibernate offers "
"automatic version checking with either an extended <literal>Session 또는 detached 인스턴스들에 대해 자동적인 버"
"전 체킹을 제공한다."

#. Tag: title
#, no-c-format
msgid "Extended session and automatic versioning"
msgstr "확장된 세션과 자동적인 버전화"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"A single <literal>Session instance and its persistent instances "
"that are used for the whole conversation are known as <emphasis>session-per-"
"conversation</emphasis>. Hibernate checks instance versions at flush time, "
"throwing an exception if concurrent modification is detected. It is up to "
"the developer to catch and handle this exception. Common options are the "
"opportunity for the user to merge changes or to restart the business "
"conversation with non-stale data."
msgstr ""
"하나의 <literal>Session 인스턴스와 그것의 영속 인스턴스들은 전체 어"
"플리케이션 트랜잭션에 사용된다. Hibernate는 flush 할 때 인스턴스 버전들을 체"
"크하고 만일 동시성 변경이 검출될 경우에 예외상황을 던진다. 이 예외상황을 잡아"
"내고 처리하는 것을 개발자의 몫이다(공통된 옵션들은 변경들을 병합시키거나 또"
"는 쓸모가 없지 않은 데이터로 비지니스 프로세스를 다시 시작하는 기회를 사용자"
"에게 주는 것이다). 하나의 <literal>Session 인스턴스와 그것의 영속 "
"인스턴스들은 <emphasis>session-per-conversation로 알려진 전체 대화"
"에 사용된다. Hibernate는 flush 시점에서 인스턴스 버전들을 체크하며, 만일 동시"
"적인 변경이 검출될 경우에 하나의 예외상황을 던진다. 이 예외상황을 포착하고 처"
"리하는 것은 개발자의 몫이다(공통된 옵션들은 사용자가 변경들을 병합하거나 손실"
"되지 않은 데이터를 가지고 비지니스 대화를 재시작하는 기회이다)."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>Session is disconnected from any underlying JDBC "
"connection when waiting for user interaction. This approach is the most "
"efficient in terms of database access. The application does not version "
"check or reattach detached instances, nor does it have to reload instances "
"in every database transaction."
msgstr ""
"<literal>Session은 사용자 상호작용을 기다릴 때 어떤 기본 JDBC 커넥"
"션으로부터 연결해제된다. 이 접근법은 데이터베이스 접근의 관점에서 보면 가장 "
"효율적이다. 어플리케이션은 버전 체킹 또는 detached 인스턴스들을 재첨부하는 것"
"에 그 자체 관계할 필요가 없거나 그것은 모든 데이터베이스 트랜잭션에서 인스턴"
"스들을 다시 로드시킬 필요가 없다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>foo object knows which Session it "
"was loaded in. Beginning a new database transaction on an old session "
"obtains a new connection and resumes the session. Committing a database "
"transaction disconnects a session from the JDBC connection and returns the "
"connection to the pool. After reconnection, to force a version check on data "
"you are not updating, you can call <literal>Session.lock() with "
"<literal>LockMode.READ on any objects that might have been updated "
"by another transaction. You do not need to lock any data that you "
"<emphasis>are updating. Usually you would set FlushMode."
"MANUAL</literal> on an extended Session, so that only the "
"last database transaction cycle is allowed to actually persist all "
"modifications made in this conversation. Only this last database transaction "
"will include the <literal>flush() operation, and then "
"<literal>close() the session to end the conversation."
msgstr ""
"<literal>foo 객체는 그것이 로드되었던 Session이 "
"어느 것인지를 여전히 알고 있다. 이전 세션 상에서 하나의 새로운 데이터베이스 "
"트랜잭션을 시작하는 것은 하나의 새로운 커넥션을 획득하고 그 세션을 소비한다. "
"데이터베이스 트랜잭션을 커밋(확약)시키는 것은 그 JDBC 커넥션으로부터 하나의 "
"세션을 연결해제시키고 그 커넥션을 풀(pool)로 반환시킬 것이다. 재연결 후에, 당"
"신이 업데이트하고 있지 않은 데이터에 대한 버전 체크를 강제시키기 위해서, 당신"
"은 또 다른 트랜잭션에 의해 업데이트되었을 수도 있는 임의의 객체들에 대해 "
"<literal>LockMode.READ로서 Session.lock()을 호출"
"할 수도 있다. 당신은 당신이 업데이트 중인 임의의 데이터를 잠금할 필요가 없"
"다. 대개 당신은 마지막 데이터베이스 트랜잭션 주기만이 이 대화 내에서 행해진 "
"모든 변경들을 실제로 영속화시키는 것이 허용되도록 하기 위해, 하나의 확장된 "
"<literal>Session에 대해 FlushMode.MANUAL를 설정"
"할 것이다. 그러므로 오직 이 마지막 데이터베이스 트랜잭션 만이 <literal>flush"
"()</literal> 오퍼레이션을 포함할 것이고, 또한 대화를 종료시키기 위해 세션을 "
"<literal>close()할 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"This pattern is problematic if the <literal>Session is too big to "
"be stored during user think time (for example, an <literal>HttpSessionSession only for a single conversation as it will soon "
"have stale data."
msgstr ""
"만일 사용자가 생각하는시간 동안 <literal>Session이 저장되기에 너무 "
"큰 경우 이 패턴은 문제성이 있다. 예를 들어 <literal>HttpSession은 "
"가능한 작은 것으로 유지되어야 한다. 또한 <literal>Session은 (필수"
"의) 첫 번째 레벨 캐시이고 모든 로드된 객체들을 포함하기 때문에, 우리는 아마 "
"적은 요청/응답 주기들에 대해서만 이 방도를 사용할 수 있다. 당신은 하나의 대화"
"에 대해서만 하나의 <literal>Session을 사용해야 한다. 왜냐하면 그것"
"은 또한 곧 실없는 데이터가 될 것이기 때문이다."

#. Tag: title
#, no-c-format
msgid "Note"
msgstr ""

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Earlier versions of Hibernate required explicit disconnection and "
"reconnection of a <literal>Session. These methods are deprecated, "
"as beginning and ending a transaction has the same effect."
msgstr ""
"(초기의 Hibernate 버전들은 <literal>Session에 대한 명시적인 연결해"
"제와 재연결을 필요로 했음을 노트하라. 트랜잭션을 시작하고 끝내는 것이 동일한 "
"효과를 가지므로, 이들 방법들은 진부하게 되었다.)"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Keep the disconnected <literal>Session close to the persistence "
"layer. Use an EJB stateful session bean to hold the <literal>Session."
msgstr ""
"또한 당신은 영속 계층에 대해 연결해제된 <literal>Session을 닫혀진채"
"로 유지해야함을 노트하라. 달 리말해, 하나의 3-tier 환경에서 "
"<literal>Session을 소유하는데 EJB stateful session bean을 사용하"
"고, <literal>HttpSession 내에 그것을 저장하기 위해 그것을 웹 계층"
"에 전송하지 말라 (또는 그것을 별도의 티어에 직렬화 시키지도 말라)."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The extended session pattern, or <emphasis>session-per-conversation for this. See the Hibernate Wiki "
"for examples."
msgstr ""
"확장된 세션 패턴, 또는 <emphasis>session-per-conversation은 자동적"
"인 현재 세션 컨텍스트 관리에 대해 구현하기가 더 어렵다. 당신은 이를 위해 당"
"신 자신의 <literal>CurrentSessionContext 구현을 공급할 필요가 있으"
"며, 예제들은 Hibernate Wiki를 보라."

#. Tag: title
#, no-c-format
msgid "Detached objects and automatic versioning"
msgstr "Detached 객체들과 자동적인 버전화"

#. Tag: para
#, no-c-format
msgid ""
"Each interaction with the persistent store occurs in a new <literal>Session "
"and then reattaches them using <literal>Session.update(), "
"<literal>Session.saveOrUpdate(), or Session.merge()에서 일"
"어난다. 하지만 동일한 영속 인스턴스들은 데이터베이스와의 각각의 상호작용에 재"
"사용된다. 어플리케이션은 원래 로드되었던 detached 인스턴스들의 상태를 또 다"
"른 <literal>Session 내에서 처리하고 나서 Session.update()"
"</literal>, Session.saveOrUpdate(), Session.merge"
"()</literal>를 사용하여 그것들을 다시 첨부시킨다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Again, Hibernate will check instance versions during flush, throwing an "
"exception if conflicting updates occurred."
msgstr ""
"다시, Hibernate는 flush 동안에 인스턴스 버전들을 체크할 것이고 업데이트 충돌"
"이 발생할 경우에 예외상황을 던질 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can also call <literal>lock() instead of update()LockMode.READ (performing a version "
"check and bypassing all caches) if you are sure that the object has not been "
"modified."
msgstr ""
"당신은 또한 <literal>update()대신에 lock()을 호"
"출할 수도 있고 만일 그 객체가 변경되지 않았음을 당신이 확신하는 경우에 (버전 "
"체킹을 수행하고 모든 캐시들을 무시하는) <literal>LockMode.READ를 사"
"용할 수 있다."

#. Tag: title
#, no-c-format
msgid "Customizing automatic versioning"
msgstr "자동적인 버전화를 맞춤화 시키기"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You can disable Hibernate's automatic version increment for particular "
"properties and collections by setting the <literal>optimistic-lock "
"mapping attribute to <literal>false. Hibernate will then no longer "
"increment versions if the property is dirty."
msgstr ""
"당신은 <literal>optimistic-lock 매핑 속성을 false in the "
"<literal><class> mapping. This conceptually only works if "
"Hibernate can compare the old and the new state (i.e., if you use a single "
"long <literal>Session and not session-per-request-with-detached-"
"objects)."
msgstr ""
"리거시 데이터베이스 스키마들은 자주 static이고 변경될 수 없다. 또는 다른 어플"
"리케이션들은 또한 동일한 데이터베이스에 접근하고 버전 번호들 또는 심지어 "
"timestamp들을 처리하는 방법을 모를 수도 있다. 두 경우들에서, 버전화는 테이블 "
"내의 특정 컬럼에 의지할 수 없다. version 또는 timestamp 프로퍼티 매핑 없이 "
"행 내의 모든 필드들에 대한 상태를 비교하여 버전 체크를 강제시키기 위해서, "
"<literal><class> 매핑 속에 optimistic-lock=\"all\"을 사용하고 "
"session-per-request-with-detached-objects을 사용하지 않을 경우 이것은 개념적"
"으로만 동작함을 노트하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Concurrent modification can be permitted in instances where the changes that "
"have been made do not overlap. If you set <literal>optimistic-lock=\"dirty"
"\"</literal> when mapping the <class>, Hibernate "
"will only compare dirty fields during flush."
msgstr ""
"때때로 행해졌던 변경들이 중첩되지 않는 한 동시적인 변경이 허용될 수 있다. 만"
"일 <literal><class>를 매핑할 때 당신이 optimistic-"
"lock=\"dirty\"</literal>를 설정하면, Hibernate는 flush 동안에 dirty 필드들을 "
"비교만 할 것이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"In both cases, with dedicated version/timestamp columns or with a full/dirty "
"field comparison, Hibernate uses a single <literal>UPDATE "
"statement, with an appropriate <literal>WHERE clause, per entity "
"to execute the version check and update the information. If you use "
"transitive persistence to cascade reattachment to associated entities, "
"Hibernate may execute unnecessary updates. This is usually not a problem, "
"but <emphasis>on update triggers in the database might be "
"executed even when no changes have been made to detached instances. You can "
"customize this behavior by setting <literal>select-before-update=\"true\"<class> mapping, forcing Hibernate "
"to <literal>SELECT the instance to ensure that changes did occur "
"before updating the row."
msgstr ""
"두 경우들에서, 전용 version/timestamp 컬럼의 경우 또는 full/dirty 필드 비교"
"의 경우, Hibernate는 법전 체크를 실행하고 정보를 업데이트하는데 엔티티 당 (적"
"절한 <literal>WHERE 절을 가진) 한 개의UPDATE 문"
"장을 사용한다. 만일 당신이 연관된 엔티티들에 대한 재첨부를 케스케이드 하는데 "
"transitive 영속을 사용할 경우, Hibernate는 불필요하게 업데이트들을 실행할 수"
"도 있다. 이것은 대개 문제가 아니지만, 심지어 변경들이 detached 인스턴스들에 "
"대해 행해지지 않았을 때에도 데이터베이스 내에서 <emphasis>on update하는 것을 "
"Hibernate에게 강제시키는, <literal><class> 매핑 속에 "
"<literal>select-before-update=\"true\"를 설정함으로써 당신은 이 특"
"징을 맞춤화 시킬 수 있다."

#. Tag: title
#, fuzzy, no-c-format
msgid "Pessimistic locking"
msgstr "Pessimistic 잠금"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"It is not intended that users spend much time worrying about locking "
"strategies. It is usually enough to specify an isolation level for the JDBC "
"connections and then simply let the database do all the work. However, "
"advanced users may wish to obtain exclusive pessimistic locks or re-obtain "
"locks at the start of a new transaction."
msgstr ""
"사용자들은 잠금 방도에 대해 걱정하는데 많은 시간을 할애하하려고 생각하지 않는"
"다. 대개 JDBC 커넥션들에 대한 격리 레벨을 지정하는 것으로 충분하고 그런 다음 "
"단순히 데이터베이스로 하여금 모든 작업을 행하도록 한다. 하지만 진일보한 사용"
"자들은 때때로 배타적인 pessimistic 잠금들을 얻거나 또는 새로운 트랜잭션의 시"
"작 시에 잠금들을 다시 얻고자 원할 수도 있다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"Hibernate will always use the locking mechanism of the database; it never "
"lock objects in memory."
msgstr ""
"Hibernate는 결코 메모리 내에 있는 객체들이 아닌, 데이터베이스의 잠금 메커니즘"
"을 항상 사용할 것이다!"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>LockMode class defines the different lock levels that "
"can be acquired by Hibernate. A lock is obtained by the following mechanisms:"
msgstr ""
"<literal>LockMode 클래스는 Hibernate에 의해 획득될 수 있는 다른 잠"
"금 레벨들을 정의한다. 잠금은 다음 메커니즘들에 의해 얻어진다:"

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockMode.WRITE is acquired automatically when Hibernate "
"updates or inserts a row."
msgstr ""
"<literal>LockMode.WRITE는 Hibernate가 한 행을 업데이트 하거나 "
"insert 할 때 자동적으로 획득된다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>LockMode.UPGRADE can be acquired upon explicit user "
"request using <literal>SELECT ... FOR UPDATE on databases which "
"support that syntax."
msgstr ""
"<literal>LockMode.UPGRADE는 SELECT ... FOR UPDATESELECT ... FOR UPDATE can be acquired upon explicit "
"user request using a <literal>SELECT ... FOR UPDATE NOWAIT under "
"Oracle."
msgstr ""
"<literal>LockMode.UPGRADE_NOWAIT는 오라클에서 SELECT ... "
"FOR UPDATE NOWAIT</literal>를 사용하여 명시적인 사용자 요청 상에서 얻어질 수"
"도 있다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>LockMode.READ is acquired automatically when Hibernate "
"reads data under Repeatable Read or Serializable isolation level. It can be "
"re-acquired by explicit user request."
msgstr ""
"<literal>LockMode.READ는 Hibernate가 반복 가능한 읽기(Repeatable "
"Read) 또는 Serialization 격리 레벨에서 데이터를 읽어들일 때 자동적으로 얻어"
"질 수도 있다. 명시적인 사용자 요청에 의해 다시 얻어질 수도 있다."

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockMode.NONE represents the absence of a lock. All "
"objects switch to this lock mode at the end of a <literal>Transactionupdate()"
"</literal> or saveOrUpdate() also start out in this lock "
"mode."
msgstr ""
"<literal>LockMode.NONE은 잠금이 없음을 나타낸다. 모든 객체들은 "
"<literal>Transaction의 끝에서 이 잠금 모드로 전환된다. "
"<literal>update() 또는 saveOrUpdate()에 대한 호"
"출을 통해 세션과 연관된 객체들이 또한 이 잠금 모드로 시작된다."

#. Tag: para
#, no-c-format
msgid ""
"The \"explicit user request\" is expressed in one of the following ways:"
msgstr "\"명시적인 사용자 요청\"은 다음 방법들 중 하나로 표현된다:"

#. Tag: para
#, no-c-format
msgid ""
"A call to <literal>Session.load(), specifying a LockMode를 지정한 Session.load()에 대"
"한 호출."

#. Tag: para
#, no-c-format
msgid "A call to <literal>Session.lock()."
msgstr "<literal>Session.lock()에 대한 호출."

#. Tag: para
#, no-c-format
msgid "A call to <literal>Query.setLockMode()."
msgstr "<literal>Query.setLockMode()에 대한 호출."

#. Tag: para
#, no-c-format
msgid ""
"If <literal>Session.load() is called with UPGRADEUPGRADE_NOWAIT, and the requested object was "
"not yet loaded by the session, the object is loaded using "
"<literal>SELECT ... FOR UPDATE. If load() is "
"called for an object that is already loaded with a less restrictive lock "
"than the one requested, Hibernate calls <literal>lock() for that "
"object."
msgstr ""
"만일 <literal>Session.load()가 UPGRADE 또는 "
"<literal>UPGRADE_NOWAIT 모드로 호출되고 ,요청된 객체가 아직 이 세션"
"에 의해 로드되지 않았다면, 그 객체는 <literal>SELECT ... FOR UPDATE"
"를 사용하여 로드된다. 만일 요청된 것이 아닌 다소 제한적인 잠금으로 이미 로드"
"되어 있는 객체에 대해 <literal>load()가 호출될 경우, Hibernate는 "
"그 객체에 대해 <literal>lock()을 호출한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>Session.lock() performs a version number check if the "
"specified lock mode is <literal>READ, UPGRADE "
"or <literal>UPGRADE_NOWAIT. In the case of UPGRADEUPGRADE_NOWAIT, SELECT ... FOR "
"UPDATE</literal> is used."
msgstr ""
"만일 지정된 잠금 모드가 <literal>READ, UPGRADE "
"또는 <literal>UPGRADE_NOWAIT 일 경우에 Session.lock()UPGRADE 또는 "
"<literal>UPGRADE_NOWAIT 인 경우에, SELECT ... FOR UPDATE would obtain a connection when it was first "
"required and then maintain that connection until the session was closed. "
"Hibernate 3.x introduced the notion of connection release modes that would "
"instruct a session how to handle its JDBC connections. The following "
"discussion is pertinent only to connections provided through a configured "
"<literal>ConnectionProvider. User-supplied connections are outside "
"the breadth of this discussion. The different release modes are identified "
"by the enumerated values of <literal>org.hibernate.ConnectionReleaseMode이 하나의 커넥션을 획득할 것이"
"고, 그런 다음 그 커넥션은 그 세션이 닫혀질때까지 보관된다는 것이었다. "
"Hibernate 3.x는 세션에게 그것의 JDBC 커넥션들을 처리하는 방법을 알려주기 위"
"해 연결 해제 모드들에 관한 개념을 도입했다. 다음 논의는 구성된 "
"<literal>ConnectionProvider를 통해 제공되는 커넥션들에 대해서만 적"
"절하다는 점을 노트하라; 사용자가 제공하는 커넥션들은 <literal>org.hibernate."
"ConnectionReleaseMode</literal>의 열거된 값들에 의해 식별된다:"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>ON_CLOSE: is the legacy behavior described above. The "
"Hibernate session obtains a connection when it first needs to perform some "
"JDBC access and maintains that connection until the session is closed."
msgstr ""
"<literal>ON_CLOSE - 는 본질적으로 위에 설명된 리거시 특징이다. "
"Hibernate 세션은 그것이 어떤 JDBC 접근을 수행하고 세션이 닫혀질 때까지 그 커"
"넥션을 보관할 필요가 있을 때 하나의 커넥션을 획득한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>AFTER_TRANSACTION: releases connections after a "
"<literal>org.hibernate.Transaction has been completed."
msgstr ""
"<literal>AFTER_TRANSACTION - 은 하나의 org.hibernate."
"Transaction</literal>이 완료된 후에 연결들을 해제하라고 말한다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>AFTER_STATEMENT (also referred to as aggressive release): "
"releases connections after every statement execution. This aggressive "
"releasing is skipped if that statement leaves open resources associated with "
"the given session. Currently the only situation where this occurs is through "
"the use of <literal>org.hibernate.ScrollableResults."
msgstr ""
"<literal>AFTER_STATEMENT (또한 적극적인 해제라고 언급됨) - 는 각각"
"의 모든 문장 실행 후에 커넥션들을 해제하라고 말한다. 이 적극적인 해제는 그 문"
"장이 주어진 세션과 연관된 리소스들을 열려진채로 남겨둘 경우에는 건너뛰게"
"(skip) 된다; 현재 이것이 일어나는 유일한 상황은 <literal>org.hibernate."
"ScrollableResults</literal>의 사용을 통해서이다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The configuration parameter <literal>hibernate.connection.release_mode (the default): this choice delegates to the release "
"mode returned by the <literal>org.hibernate.transaction.TransactionFactory."
"getDefaultReleaseMode()</literal> method. For JTATransactionFactory, this "
"returns ConnectionReleaseMode.AFTER_STATEMENT; for JDBCTransactionFactory, "
"this returns ConnectionReleaseMode.AFTER_TRANSACTION. Do not change this "
"default behavior as failures due to the value of this setting tend to "
"indicate bugs and/or invalid assumptions in user code."
msgstr ""
"<literal>auto (디폴트) - 이 선택은 org.hibernate."
"transaction.TransactionFactory.getDefaultReleaseMode()</literal> 메소드에 의"
"해 반환된 해제 모드로 위임시킨다. JTATransactionFactory인 경우, 이것은 "
"ConnectionReleaseMode.AFTER_STATEMENT를 반환한다; JDBCTransactionFactory인 경"
"우, 이것은 ConnectionReleaseMode.AFTER_TRANSACTION을 반환한다. 이 설정의 값"
"이 사용자 코드 내의 버그들 그리고/또는 유효하지 않은 가정들을 가리키는 경향"
"이 있음으로 인해 이 디폴트 특징을 실패로 변경하는 것은 거의 좋은 생각이 아니"
"다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>on_close: uses ConnectionReleaseMode.ON_CLOSE. This "
"setting is left for backwards compatibility, but its use is discouraged."
msgstr ""
"<literal>on_close - 는 ConnectionReleaseMode.ON_CLOSE를 사용하라고 "
"말한다. 이 설정은 역호환성을 위해 남겨졌지만, 그것의 사용은 매우 권장되지 않"
"는다."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>after_transaction: uses ConnectionReleaseMode."
"AFTER_TRANSACTION. This setting should not be used in JTA environments. Also "
"note that with ConnectionReleaseMode.AFTER_TRANSACTION, if a session is "
"considered to be in auto-commit mode, connections will be released as if the "
"release mode were AFTER_STATEMENT."
msgstr ""
"<literal>after_transaction - 은 ConnectionReleaseMode."
"AFTER_TRANSACTION을 사용하라고 말한다. 이 설정은 JTA 환경들에서 사용되지 않"
"을 것이다. 또한 ConnectionReleaseMode.AFTER_TRANSACTION인 경우에 만일 세션이 "
"auto-commit 모드에 있도록 고려될 경우, 커넥션들은 마치 해제 모드가 "
"AFTER_STATEMENT인 것처럼 해제될 것임을 또한 노트하라."

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"<literal>after_statement: uses ConnectionReleaseMode."
"AFTER_STATEMENT. Additionally, the configured <literal>ConnectionProvider). If not, the release mode "
"is reset to ConnectionReleaseMode.AFTER_TRANSACTION. This setting is only "
"safe in environments where we can either re-acquire the same underlying JDBC "
"connection each time you make a call into <literal>ConnectionProvider."
"getConnection()</literal> or in auto-commit environments where it does not "
"matter if we re-establish the same connection."
msgstr ""
"<literal>after_statement - 는 ConnectionReleaseMode.AFTER_STATEMENT"
"를 사용하라고 말한다. 추가적으로 구성된 <literal>ConnectionProvider"
"는 그것이 이 설정 (<literal>supportsAggressiveRelease())을 지원하는"
"지 여부를 알기 위해 참고된다. 만일 지원하지 않을 경우, 해제 모드는 "
"ConnectionReleaseMode.AFTER_TRANSACTION으로 재설정된다. 이 설정은 우리가 "
"<literal>ConnectionProvider.getConnection()을 호출할 때마다 우리가 "
"동일한 기본 JDBC 커넥션을 다시 필요로 할 수 있는 환경들에서 또는 우리가 동일"
"한 커넥션을 얻는 것에 상관없는 auto-commit 환경에서 오직 안전하다."

#~ msgid "foo==bar"
#~ msgstr "foo==bar"