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、およびデータベース管理システム（DBMS）のト"
"ランザクション分離の仕様を 少し時間をかけて勉強することを強く推奨します。"

#. 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はメモリ内のオブジェクトをロックしません。 アプリケーションは、デー"
"タベーストランザクションの分離レベルで 定義した振る舞いを期待できます。 トラ"
"ンザクションスコープのキャッシュでもある <literal>Session</literal> のお陰"
"で、 識別子やクエリにより検索したエンティティはリピータブルリードになります "
"（スカラー値を返すようなレポートクエリは違います）。"

#. 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 ""
"バージョニングによる自動的な楽観的同時実行制御に加えて、 <literal>SELECT FOR "
"UPDATE</literal> 文を使用して、 行を悲観的ロックするための（マイナーな）APIも"
"提供します。 楽観的同時実行制御とこの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 ""
"データベーストランザクションや長い対話（conversation、ロングトランザクショ"
"ン）だけでなく、 <literal>Configuration</literal>、<literal>SessionFactory</"
"literal>、および <literal>Session</literal> という粒度でHibernateが行う同時実"
"行制御の議論を始めます。"

#. Tag: title
#: transactions.xml:36
#, no-c-format
msgid "Session and transaction scopes"
msgstr "sessionスコープとtransactionスコープ"

#. 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> は生成することが高価で、 スレッドセーフなオ"
"ブジェクトです。 よって、アプリケーションのすべてのスレッドで共有すべきで"
"す。 通常、アプリケーションの起動時に、 <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> は高価ではなく、スレッドセーフなオブジェクトでもあ"
"りません。 よって、１つの要求や１つの対話、１つの作業単位（unit of work）に対"
"して１度だけ使い、 その後で捨てるべきです。 <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> は、 いくつかのデータベーストランザクションをまたがることができるで"
"しょうか？ または、スコープと一対一の関係でしょうか？ いつ <literal>Session</"
"literal> を開き、閉じるべきでしょうか？ そして、データベーストランザクション"
"境界をどのように分けるのでしょうか？"

#. Tag: title
#: transactions.xml:69
#, no-c-format
msgid "Unit of work"
msgstr "作業単位（Unit of work）"

#. 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> アンチパターンを使っては"
"いけません。 すなわち、１つのスレッドの中で、単純なデータベース呼び出しのたび"
"に <literal>Session</literal> を開いて、閉じてはいけません！ もちろん、データ"
"ベーストランザクションについても同様です。 アプリケーション中のデータベース呼"
"び出しは、 計画されたシーケンス（planned sequence）を使い、 アトミックな作業"
"単位に分類されます。 （１つのSQL文ごとにコミットする自動コミットが、 使われな"
"いという意味でもあることに注意してください。 自動コミットは、SQLコンソールで"
"アドホックな作業をする際に使うものです。 Hibernateは直ちに自動コミットモード"
"を無効にします。 もしくは、アプリケーションサーバーが無効化することを期待しま"
"す。） データベーストランザクションはオプションではありません。 データベース"
"とのすべての通信は、データの読み込みであっても、書き込みであっても、 トランザ"
"クションの中で行わなければなりません。 説明すると、データ読み込みに対して、自"
"動コミットは避けるべきです。 なぜなら、多数の小さなトランザクションは、明確に"
"定義された１つの作業単位と比べて、 パフォーマンスがよくなることはありませ"
"ん。 後者は保守性や拡張性もよりすぐれています。"

#. 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> が開かれます。 そして、こ"
"の作業単位の中ですべてのデータベース処理が実行されます。 作業が完了した（そし"
"て、クライアントへのレスポンスが準備できた）時点で、 session をフラッシュし、"
"閉じます。 クライアントの要求を処理するために、１つのデータベーストランザク"
"ションを使用するでしょう。 <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は単純なこのパターンのために、"
"予め組み込まれた 「current session」の管理を提供します。 サーバーリクエストを"
"処理する際はトランザクションを開始しなければなりません。 そして、レスポンスを"
"クライアントに送信する前にトランザクションを終わらせます。 好きな方法で実現で"
"きます。一般的な解決策は <literal>ServletFilter</literal> や サービスメソッド"
"をポイントカットしてAOPインターセプター、 proxy/interception コンテナです。 "
"EJBコンテナはEJBセッションビーンをトランザクション境界として アスペクトをクロ"
"スカットする実装の標準的な方法です（CMTによる宣言的）。 プログラムによるトラ"
"ンザクション境界を使うと決めた場合、 簡単に使うため、互換性のあるコードにする"
"ために、 この章の後のほうにあるHibernate <literal>Transaction</literal> APIの"
"ほうがよいです。"