transactions.po

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

#. 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\"/>."
msgstr ""
"アプリケーションのコードは、必要なときにどこでも、何回でも、 単に "
"<literal>sessionFactory.getCurrentSession()</literal> を呼び出すだけで 「現在"
"のセッション」にアクセスできます。 現在のデータベーストランザクションへの "
"<literal>セッション</literal> を常に取得します。 リソース・ローカルな環境、も"
"しくはJTA環境を構成しなければなりません （<xref linkend=\"architecture-"
"current-session\"/> を参照してください）。"

#. Tag: para
#: transactions.xml:120
#, 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>セッション</literal> とデータベー"
"ストランザクションのスコープを拡張すると便利なことがあります。 これは、要求の"
"処理と描画のフェーズを分けている サーブレットアプリケーションにおいて特に役立"
"ちます。 独自のインターセプタを実装すれば、 ビューを描画するまでデータベース"
"トランザクションを拡張するのは簡単です。 しかし、コンテナ管理トランザクション"
"のEJBに頼る場合は、簡単にはできません。 なぜなら、ビューの描画を開始する前"
"に、EJBのメソッドがリターンした際に、 トランザクションが完了するためです。 こ"
"の <emphasis>Open Session in View</emphasis> パターンに関連するヒントと例につ"
"いては、 HibernateのWebサイトやフォーラムを参照してください。"

#. Tag: title
#: transactions.xml:135
#, no-c-format
msgid "Long conversations"
msgstr "長い対話"

#. Tag: para
#: transactions.xml:137
#, 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パターンは、作業単位を設計する際に役立つ考えというだけでは"
"ありません。 多くのビジネスプロセスは、ユーザーとの一連の相互作用全体を要求し"
"ます。 その相互作用には、データベースアクセスが含まれます。 Webとエンタープラ"
"イズアプリケーションでは、データベーストランザクションが ユーザとの相互作用に"
"まで渡ることは許されません。 次の例をよく考えてみてください。"

#. Tag: para
#: transactions.xml:147
#, 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:154
#, 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分後にユーザーは「Save」をクリックし、修正が永続化されるのを期待します。 ま"
"た、この情報を編集したのは自分１人だけで、 修正のコンフリクトは発生しないと期"
"待します。"

#. Tag: para
#: transactions.xml:162
#, 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:168
#, 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 ""
"最初に思いつく実装は、ユーザーが考えている間、<literal>Session</literal> と"
"データベーストランザクションを開いたままにしておくことです。 同時に修正され"
"ず、分離と原子性が保証されるように、 データベース内のロックは保持したままにし"
"ます。 もちろん、これはアンチパターンです。 なぜなら、ロックの競合が発生する"
"と、 アプリケーションが同時ユーザー数に応じてスケールアップできなくなるからで"
"す。"

#. Tag: para
#: transactions.xml:176
#, no-c-format
msgid ""
"Clearly, we have to use several database transactions to implement the "
"converastion. 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 ""
"明らかに、対話を実装するためには、 いくつかのデータベーストランザクションを使"
"用するべきです。 この場合、ビジネスプロセスの分離を維持することは、 アプリ"
"ケーション層の責務の１つになります。 １つの対話は、 通常いくつかのデータベー"
"ストランザクションに及びます。 データベーストランザクションの１つのみ（最後の"
"１つ）が更新したデータを保存し、 他はデータを読むだけであれば、それはアトミッ"
"クです （例えば、いくつかの要求／応答を繰り返すウィザード形式のダイアロ"
"グ）。 これは聞くより、実装したほうが簡単です。 Hibernateの機能を使うのであれ"
"ば、特に簡単です。"

#. Tag: para
#: transactions.xml:189
#, 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 occured during user think time. Usually we only "
"check at the end of the conversation."
msgstr ""
"<emphasis>自動バージョニング</emphasis> - Hibernateは自動的に楽観的同時実行制"
"御ができます。 ユーザーが考えている間に同時に修正がおきた場合、自動的に検出で"
"きます。 通常、対話の終了時にチェックするだけです。"

#. Tag: para
#: transactions.xml:197
#, 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> パターンを使うと決定した場合、 ロー"
"ドされたすべてのインスタンスは、ユーザが考えている間は、 セッションから分離さ"
"れた状態になります。 オブジェクトをセッションに再追加し、修正を永続化できま"
"す。 これを <emphasis>session-per-request-with-detached-objects</emphasis> パ"
"ターンと呼びます。 自動バージョニングを使うことで、同時に行われる修正を分離で"
"きます。"

#. Tag: para
#: transactions.xml:207
#, 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 explicitely."
msgstr ""
"<emphasis>拡張（もしくは、長い）セッション</emphasis> - Hibernateの "
"<literal>Session</literal> は、 データベーストランザクションをコミットした"
"後、 裏で結びついているJDBCコネクションを切断できます。 そして、クライアント"
"からの新しい要求が発生した際に、再接続できます。 このパターンは、"
"<emphasis>session-per-conversation</emphasis> という名で知られており、オブ"
"ジェクトをセッションへ再追加することさえ不要にします。 自動バージョニングを使"
"うことで、同時に行われる修正を分離できます。 通常 <literal>Session</literal> "
"を自動的にフラッシュさせず、 明示的にフラッシュします。"

#. Tag: para
#: transactions.xml:220
#, 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> の２つは、 利点と欠点を持ってい"
"ます。 これについては、この章の後のほうで、楽観的同時実行制御の文脈の中で議論"
"します。"

#. Tag: title
#: transactions.xml:229
#, no-c-format
msgid "Considering object identity"
msgstr "オブジェクト識別子を考える"

#. Tag: para
#: transactions.xml:231
#, 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> インスタ"
"ンスが 永続性クラスの１つのインスタンスを共有することはできません。 ゆえに、"
"識別子には２つの異なる概念があるということになります。"

#. Tag: term
#: transactions.xml:240
#, no-c-format
msgid "Database Identity"
msgstr "データベース識別子"

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

#. Tag: term