transactions.po

hibernate-distribution-3.3.1.GA-dist.zip源码

msgstr ""
"당신의 어플리케이션 코드는 어디서든 필요할 때 종종 <literal>sessionFactory."
"getCurrentSession()</literal>을 간단히 호출함으로써 요청을 처리할 \"현재 세션"
"\"에 접근할 수 있다. 당신은 현재 데이터베이스 트랜잭션으로 영역화된 하나의 "
"<literal>Session</literal>을 항상 얻게 될 것이다. 이것은 resource-local 환경 "
"또는 JTA 환경에 대해 구성되어야 하며, <xref linkend=\"architecture-current-"
"session\"/>을 보라."

#. Tag: para
#: transactions.xml:144
#, no-c-format
msgid ""
"Sometimes it is convenient to extend the scope of a <literal>Session</"
"literal> 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 complete is easy to do if you implement "
"your own interceptor. However, it is not easily doable if you rely on EJBs "
"with container-managed transactions, as 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 around this <emphasis>Open "
"Session in View</emphasis> pattern."
msgstr ""
"때때로 \"뷰가 렌더링될 때까지\" 하나의 <literal>Session</literal> 과 데이터베"
"이스 트랜잭션의 영역을 확장시키는 것이 편리하다. 이것은 요청이 처리된 후에 하"
"나의 별도의 렌더링 단계를 활용하는 서블릿 어플리케이션들에서 특히 유용하다. "
"뷰 렌더링이 완료될 때까지 데이터베이스 트랜잭션을 확장하는 것은 당신이 당신 "
"자신의 인터셉터를 구현하는 경우에 행하기가 쉽다. 하지만 만일 당신이 컨테이너"
"에 의해 관리되는 트랜잭션들을 가진 EJB들에 의존할 경우에, 하나의 EJB 메소드"
"가 반환될 때 임의의 뷰 렌더링이 시작될 수 있기 전에 하나의 트랜잭션이 완료되"
"기 때문에, 행하는 것이 쉽지 않다. 이 <emphasis>Open Session in View</"
"emphasis> 패턴을 둘러싼 팁들과 예제들은 Hibernate 웹 사이트와 포럼을 보라."

#. Tag: title
#: transactions.xml:159
#, no-c-format
msgid "Long conversations"
msgstr "장기간의 대화"

#. Tag: para
#: transactions.xml:161
#, no-c-format
msgid ""
"The session-per-request pattern is not the only useful concept you can use "
"to design units of work. Many business processes require a whole series of "
"interactions with the user interleaved with database accesses. In web and "
"enterprise applications it is not acceptable for a database transaction to "
"span a user interaction. Consider the following example:"
msgstr ""
"session-per-request 패턴은 당신이 작업 단위들을 설계하는데 사용할 수 있는 유"
"일한 유용한 개념이 아니다. 많은 비지니스 프로세스들은 데이터베이스 접근들을 "
"중재하는 사용자 사이의 전체 일련의 상호작용들을 필요로 한다. 웹과 엔터프라이"
"즈 어플리케이션에서 사용자 상호작용에 걸치는 것은 데이터베이스 트랜잭션에 허"
"용되지 않는다. 다음 예제를 검토하자:"

#. Tag: para
#: transactions.xml:171
#, no-c-format
msgid ""
"The first screen of a dialog opens, the data seen by the user has been "
"loaded in a particular <literal>Session</literal> and database transaction. "
"The user is free to modify the objects."
msgstr ""
"대화상자의 첫 번째 화면이 열리고, 사용자에게 보여진 데이터는 특정 "
"<literal>Session</literal>과 데이터베이스 트랜잭션 속에 로드되었다. 사용자가 "
"객체들을 변경시키는 것이 자유롭다."

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

#. Tag: para
#: transactions.xml:186
#, no-c-format
msgid ""
"We call this unit of work, from the point of view of the user, a long "
"running <emphasis>conversation</emphasis> (or <emphasis>application "
"transaction</emphasis>). There are many ways how you can implement this in "
"your application."
msgstr ""
"우리는 사용자의 관점에서, 이것을 작업 단위, 장기간 실행되는 <emphasis>대화</"
"emphasis> (또는 <emphasis>어플리케이션 트랜잭션</emphasis>)이라고 명명한다. "
"당신이 당신의 어플리케이션에서 이것을 어떻게 구현할 수 있는 많은 방법들이 존"
"재한다."

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

#. Tag: para
#: transactions.xml:200
#, fuzzy, no-c-format
msgid ""
"Clearly, we 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 (e.g. in a wizard-style dialog spanning "
"several request/response cycles). This is easier to implement than it might "
"sound, especially if you use Hibernate's features:"
msgstr ""
"명료하게, 우리는 대화(<emphasis>어플리케이션 트랜잭션</emphasis>)를 구현하는"
"데 몇몇 데이터베이스 트랜잭션들을 사용해야 한다. 이 경우에, 비지니스 프로세스"
"들의 격리를 유지하는 것은 어플리케이션 티어의 부분적인 책임이 된다. 단일 대화"
"는 대개 여러 개의 데이터베이스 트랜잭션들에 걸친다. 그것은 이들 데이터베이스 "
"트랜잭션들 중 오직 한 개(마지막 트랜잭션)가 업데이트된 데이터를 저장하고, 모"
"든 다른 트랜잭션들이 단순히 데이터를 읽는 (예를 들면, 몇몇 요청/응답 주기에 "
"걸치는 마법사 스타일의 대화 상자에서) 경우에만 원자단위가 될 것이다. 특히 당"
"신이 Hibernate의 특징들을 사용할 경우에 , 이것은 들리는 것보다 구현하기가 더 "
"쉽다:"

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

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

#. Tag: para
#: transactions.xml:231
#, fuzzy, no-c-format
msgid ""
"<emphasis>Extended (or Long) Session</emphasis> - The Hibernate "
"<literal>Session</literal> may 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</literal> is usually not allowed to "
"be flushed automatically, but explicitly."
msgstr ""
"<emphasis>확장된 (또는 Long) Session</emphasis> - Hibernate "
"<emphasis>Session</emphasis>은 데이터베이스 트랜잭션이 커밋된 후에 기본 JDBC "
"커넥션이 연결 해제될 수도 있고, 새로운 클라이언트 요청이 발생할 때 다시 연결"
"될 수 있다. 이 패턴은 <emphasis>session-per-conversation(대화 당 세션)</"
"emphasis>으로 알려져 있고 재첨부를 불필요하게 만든다. 자동적인 버전화는 동시"
"성 변경들을 격리시키는데 사용되고 <literal>Session</literal>은 자동적으로 "
"flush되는 것이 허용되지 않지만 명시적으로 flush되는 것은 허용된다."

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

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

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

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

#. Tag: literal
#: transactions.xml:267
#, no-c-format
msgid "foo.getId().equals( bar.getId() )"
msgstr "foo.getId().equals( bar.getId() )"

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

#. Tag: literal
#: transactions.xml:275
#, no-c-format
msgid "foo==bar"
msgstr "foo==bar"

#. Tag: para
#: transactions.xml:281
#, fuzzy, no-c-format
msgid ""
"Then for objects attached to a <emphasis>particular</emphasis> "
"<literal>Session</literal> (i.e. in the scope of a <literal>Session</"
"literal>) the two notions are equivalent, and JVM identity for database "
"identity is guaranteed by Hibernate. However, while the application might "