transactions.po

hibernate 开源框架的代码 jar包希望大家能喜欢

msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2007-10-25 07:47+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <[e-mail]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Tag: title
#: transactions.xml:5
#, no-c-format
msgid "Transactions And Concurrency"
msgstr "트랜잭션들과 동시성"

#. Tag: para
#: transactions.xml:7
#, no-c-format
msgid ""
"The most important point about Hibernate and concurrency control is that it "
"is very easy to understand. Hibernate directly uses JDBC connections and JTA "
"resources without adding any additional locking behavior. We highly "
"recommend 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
#: transactions.xml:14
#, 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. "
"Note that thanks to the <literal>Session</literal>, which is also a "
"transaction-scoped cache, Hibernate provides repeatable reads for lookup by "
"identifier and entity queries (not reporting queries that return scalar "
"values)."
msgstr ""
"Hibernate는 메모리 내에서 객체들을 잠그지 않는다. 당신의 어플리케이션은 격리 "
"레벨에 의해 정의된 대로 행위를 기대할 수 있다. 또한 transaction-영역의 캐시"
"인 <literal>Session</literal> 덕분에, Hibernate는 (스칼라 값들을 반환하는 질"
"의들을 보고하지 않는) 식별자와 엔티티 질의들에 의한 룩업을 위해 반복 가능한 "
"읽기를 제공한다."

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

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

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

#. Tag: para
#: transactions.xml:38
#, no-c-format
msgid ""
"A <literal>SessionFactory</literal> 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</literal> "
"instance."
msgstr ""
"<literal>SessionFactory</literal>는 모든 어플리케이션 쓰레드들에 의해 공유되"
"도록 고안된 생성에 비용이 드는, 쓰레드안전(threadsafe) 객체이다. 그것은 대개 "
"어플리케이션 시작 시에 <literal>Configuration</literal> 인스턴스로부터 한번 "
"생성된다."

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

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

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

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

#. Tag: para
#: transactions.xml:71
#, no-c-format
msgid ""
"First, don't use the <emphasis>session-per-operation</emphasis> antipattern, "
"that is, don't open and close a <literal>Session</literal> for every simple "
"database call in a single thread! Of course, 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. (Note that this also "
"means that auto-commit after every single SQL statement is useless in an "
"application, this mode is intended for ad-hoc SQL console work. Hibernate "
"disables, or expects the application server to do so, auto-commit mode "
"immediately.) Database transactions are never optional, all communication "
"with a database has to occur inside a transaction, no matter if you read or "
"write data. As explained, 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 much more maintainable and "
"extensible."
msgstr ""
"첫번째로, <emphasis>session-per-operation</emphasis> anti-패턴을 사용하지 말"
"라. 즉, 단일 쓰레드 내에서 모든 간단한 데이터베이스 호출에 대해 "
"<literal>Session</literal>을 열고 닫지 말라! 물론 같은 것이 데이터베이스 트랜"
"잭션들에 대해서도 참이다. 어플리케이션 내의 데이터베이스 호출들은 계획된 순서"
"를사용하여 행해지며, 그것들은 원자 작업 단위 속으로 그룹지워진다. (이것은 또"
"한 모든 하나의 SQL 문장 뒤의 auto-commit(자동-커밋)이 어플리케이션 내에서 무"
"용지물임을 의미하고, 이 모드가 SQL 콘솔 작업을 돕도록 고안되었음을 노트하라. "
"Hibernate는 의미하고, 이 모드는 Hibernate는 즉시 자동-커밋 모드를 사용 불가능"
"하게 하거나, 어플리케이션 서버가 그렇게 행하고, 즉시 자동-커밋시키는 것을 사"
"용불가능하게 하거나 ,그렇게 행하는 것을 기대한다.) 데이터베이스 트랜잭션들은 "
"결코 옵션이 아니며, 하나의 데이터베이스와의 모든 통신은 당신이 데이터를 읽든 "
"쓰단간에 상관없이 하나의 트랜잭션 내에서 발생해야 한다. 설명하였듯이, 데이터 "
"읽기를 위한 auto-commit 특징을 피해야 할 것이며, 많은 작은 트랜잭션들은 하나"
"의 명료하게 정의된 작업 단위보다 더 좋게 수행될 것 같지 않다. 후자가 또한 훨"
"씬 더 유지가능하고 확장적이다."

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

#. Tag: para
#: transactions.xml:99
#, no-c-format
msgid ""
"The challenge lies in the implementation. Hibernate provides built-in "
"management of the \"current session\" to simplify this pattern. All you have "
"to do is start a transaction when a server request has to be processed, and "
"end the transaction before the response is send to the client. You can do "
"this in any way you like, common solutions are <literal>ServletFilter</"
"literal>, 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 decide to use programmatic transaction "
"demarcation, prefer the Hibernate <literal>Transaction</literal> API shown "
"later in this chapter, for ease of use and code portability."
msgstr ""
"난제는 구현에 놓여있다: Hibernate는 이 패턴을 단순화 시키기 위해 \"현재 세션"
"\"에 관한 미리 빌드된 관리를 제공한다. 당신이 행해야할 모든 것은 서버 요청이 "
"처리되어야 할 때 트랜잭션을 시작하고, 그 응답이 클라이언트로 전송되기 전에 트"
"랜잭션을 끝내는 것이다. 당신은 당신이 좋아하는 임의의 방법으로 이것을 행할 "
"수 있으며, 공통된 해결책들은 서비스 메소드들 상의 첨단, 또는 하나의 프락시/인"
"터셉션 컨테이너를 가진 APO 인터셉터인, <literal>ServletFilter</literal>이다. "
"하나의 EJB 컨테이너는 CMT의 경우에 선언적으로 EJB session beans 상에 트랜잭"
"션 경계구분과 같은 동시 대조 측면들을 구현하는 표준 방법이다. 만일 당신이 프"
"로그램 상의 트랜잭션 경계구분을 사용하고자 결정한다면, 사용의 용이성과 코드 "
"이식성을 위해 이 장의 뒷 부분에서 보여진 Hibernate <literal>Transaction</"
"literal>을 선호하라."

#. Tag: para
#: transactions.xml:112
#, no-c-format
msgid ""
"Your application code can access a \"current session\" to process the "
"request by simply calling <literal>sessionFactory.getCurrentSession()</"
"literal> anywhere and as often as needed. You will always get a "
"<literal>Session</literal> scoped to the current database transaction. This "
"has to be configured for either resource-local or JTA environments, see "
"<xref linkend=\"architecture-current-session\"/>."