transactions.po

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

"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 (automatic versioning) at "
"flush/commit time, using an optimistic approach."
msgstr ""
"그때 (예를 들어 <literal>Session</literal> 영역에서) <emphasis>특정</"
"emphasis><literal>Session</literal>에 첨부된 객체들의 경우 두 개의 개념들은 "
"동등한 것이고, 데이터베이스 identity에 대한 JVM identity가 Hibernate에 의해 "
"보장된다. 하지만, 어플리케이션이 두 개의 다른 세션들에서 \"동일한\" (영속 "
"identity) 비지니스 객체에 동시에 접근하는 동안, 두 개의 인스턴스들은 실제로 "
"\"다르다\"(JVM identity). 충돌들은 flush/커밋 시에 (자동적인 버전화)를 사용하"
"여, optimistic 접근법을 사용하여 해결된다."

#. Tag: para
#: transactions.xml:290
#, 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 only doesn't need expensive locking or other means of "
"synchronization. The application never needs to synchronize on any business "
"object, as long as it sticks to a single thread per <literal>Session</"
"literal>. Within a <literal>Session</literal> the application may safely use "
"<literal>==</literal> to compare objects."
msgstr ""
"이 접근법은 Hibernate와 데이터베이스가 동시성에 대해 걱정하지 않도록 해준다; "
"그것은 또한 최상의 scalability를 제공한다. 왜냐하면 단일 쓰레드-작업 단위 내"
"에서 identity 보장은 단지 비용이 드는 잠금이나 다른 동기화 수단들을 필요로 하"
"지 않기 때문이다. 어플리케이션은 그것이 <literal>Session</literal> 당 단일 쓰"
"레드를 강제하는 한, 어떤 비지니스 객체에 대해 결코 동기화 시킬 필요가 없다. "
"하나의 <literal>Session</literal> 내에서 어플리케이션은 객체들을 비교하는데 "
"<literal>==</literal>를 안전하게 사용할 수가 있다."

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

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

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

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

#. Tag: para
#: transactions.xml:342
#, no-c-format
msgid ""
"An exception thrown by Hibernate means you have to rollback your database "
"transaction and close the <literal>Session</literal> immediately (discussed "
"later in more detail). If your <literal>Session</literal> is bound to the "
"application, you have to stop the application. Rolling back the database "
"transaction doesn't put your business objects back into the state they were "
"at the start of the transaction. This means the database state and the "
"business objects do get out of sync. Usually this is not a problem, because "
"exceptions are not recoverable and you have to start over after rollback "
"anyway."
msgstr ""
"Hibernate에 의해 던져진 예외상황은 당신이 당신의 데이터베이스 트랜잭션을 롤"
"백 시키고 즉시 <literal>Session</literal>을 닫아야 함을 의미한다(나중에 상세"
"히 논의됨). 만일 당신의 <literal>Session</literal>이 어플리케이션에 바인드 되"
"어 있는 경우, 당신은 어플리케이션을 중지시켜야 한다. 데이터베이스 트랜잭션 롤"
"백은 당신의 비지니스 객체들을 그것들이 트랜잭션의 시작 시에 머물렀던 상태로 "
"되돌리지는 않는다. 이것은 데이터베이스 상태와 비지니스 객체들이 동기화를 벗어"
"남을 의미한다. 대개 이것은 문제가 아니다. 왜냐하면 예외상황들은 회복가능한 것"
"이 아니고 당신이 어떻게든 롤백 후에 시작해야 하기 때문이다."

#. Tag: para
#: transactions.xml:354
#, no-c-format
msgid ""
"The <literal>Session</literal> caches every object that is in persistent "
"state (watched and checked for dirty state by Hibernate). This means it "
"grows endlessly until you get an OutOfMemoryException, if you keep it open "
"for a long time or simply load too much data. One solution for this is to "
"call <literal>clear()</literal> and <literal>evict()</literal> to manage the "
"<literal>Session</literal> cache, but you most likely should consider a "
"Stored Procedure if you need mass data operations. Some solutions are shown "
"in <xref linkend=\"batch\"/>. Keeping a <literal>Session</literal> open for "
"the duration of a user session also means a high probability of stale data."
msgstr ""
"<literal>Session</literal>은 (Hibernate에 의해 dirty 상태로 관찰되었거나 체크"
"된) 영속 상태에 있는 모든 객체를 캐시 시킨다. 이것은 당신이 오랜 시간 동안 "
"<literal>Session</literal>을 열어둔 채로 유지하거나 단순하게 너무 많은 데이터"
"를 로드시킬 경우에, 당신이 OutOfMemoryException을 얻기 전까지, 그것이 끝없이 "
"성장한다는 점을 의미한다. 이것에 대한 하나의 해결책은 <literal>Session</"
"literal> 캐시를 관리하기 위해 <literal>clear()</literal>와 <literal>evict()</"
"literal>를 호출하는 것이지만, 당신이 대용량 데이터 오퍼레이션들을 필요로 하"
"는 경우에 당신은 대개 내장 프로시저를 고려해야 할 것이다. 몇몇 해결책들이 "
"<xref linkend=\"batch\"/>에 보여져 있다. 사용자 세션 동안에 "
"<literal>Session</literal>을 열려진 채로 유지하는 것은 또한 실효성이 떨어진 "
"데이터에 대한 높은 확률을 의미한다."

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

#. Tag: para
#: transactions.xml:374
#, 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
#: transactions.xml:384
#, 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, in other words, begin, commit, or rollback database transactions "
"himself. 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
#: transactions.xml:394
#, 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 you'd use programmatic "
"transaction demarcation. Hibernate offers a wrapper API called "
"<literal>Transaction</literal> 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</literal>이라 명명되는 wrapper API 를 제공한"
"다. 이 API는 실제로 옵션이지만 우리는 당신이 CMT session bean 속에 있지 않는 "
"한 그것의 사용을 강력하게 권장한다."

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

#. Tag: para
#: transactions.xml:409