transactions.po

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

"catch (RuntimeException e) {\n"
"    tx.rollback();\n"
"    throw e; // or display error message\n"
"}]]>"
msgstr ""

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

#. Tag: programlisting
#: transactions.xml:513
#, no-c-format
msgid ""
"<![CDATA[// CMT idiom\n"
" Session sess = factory.getCurrentSession();\n"
"\n"
" // do some work\n"
" ...\n"
"]]>"
msgstr ""

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

#. Tag: para
#: transactions.xml:523
#, fuzzy, no-c-format
msgid ""
"Note that you should 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, when you configure Hibernate's transaction factory. Remember "
"to also set <literal>hibernate.transaction.manager_lookup_class</literal>. "
"Furthermore, make sure that your <literal>hibernate."
"current_session_context_class</literal> is either unset (backwards "
"compatibility), or set to <literal>\"jta\"</literal>."
msgstr ""
"당신이 Hibernate의 트랜잭션 팩토리를 구성할 때, 당신이 JTA를 직접 사용할 경우"
"(BMT) 당신은 <literal>org.hibernate.transaction.JTATransactionFactory</"
"literal>를 선택해야하고, CMT session bean에서는 <literal>org.hibernate."
"transaction.CMTTransactionFactory</literal>를 선택해야 함을 노트하라. 또한 "
"<literal>org.hibernate.transaction.manager_lookup_class</literal>를 설정하는 "
"것을 염두에 두라. 게다가 반드시 당신의 <literal>hibernate."
"current_session_context_class</literal>이 설정되지 않도록 하거나(역호환성), "
"또는 <literal>\"jta\"</literal>로 설정되도록 하라."

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

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

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

#. Tag: para
#: transactions.xml:561
#, no-c-format
msgid ""
"The <literal>HibernateException</literal>, which wraps most of the errors "
"that can occur in a Hibernate persistence layer, is an unchecked exception "
"(it wasn't in older versions of Hibernate). In our opinion, we shouldn't "
"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 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 which are not a <literal>HibernateException</literal>. "
"These are, again, not recoverable and appropriate action should be taken."
msgstr ""
"Hibernate 영속 계층에서 발생할 수 있는 대부분의 오류들을 포장하는, "
"<literal>HibernateException</literal>은 체크되지 않은 예외상황이다(그것은 "
"Hibernate의 이전 버전에는 없었다). 우리의 의견으로, 우리는 낮은 계층에서 복구"
"불가능한 예외상황을 붙잡도록 어플리케이션 개발자에게 강제하지 않을 것이다. 대"
"부분의 시스템들에서, 체크되지 않은 치명적인 예외상황들은 (예를 들어, 더 높은 "
"계층에서) 메소드 호출 스택의 첫 번째 프레임들 중 하나 속에서 처리되고, 한 개"
"의 오류 메시지가 어플리케이션 사용자에게 표시된다(또는 어떤 다른 적절한 액션"
"이 취해진다). Hibernate는 또한 <literal>HibernateException</literal>이 아닌, "
"다른 체크되지 않은 예외상황들을 던질 수도 있음을 노트하라. 다시 이것들은 복구"
"가능하지 않고 적절한 액션이 취해져야 한다."

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

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

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

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

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

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

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

#. Tag: para
#: transactions.xml:625
#, fuzzy, no-c-format
msgid ""
"One extremely 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