transactions.po

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

#: transactions.xml:248
#, no-c-format
msgid "JVM Identity"
msgstr "JVM識別子"

#. Tag: literal
#: transactions.xml:251
#, no-c-format
msgid "foo==bar"
msgstr "foo==bar"

#. Tag: para
#: transactions.xml:257
#, fuzzy, no-c-format
msgid ""
"Then for objects attached to a <emphasis>particular</emphasis> "
"<literal>Session</literal> (i.e. in the scope of a <literal>Session</"
"literal>) the two notions are equivalent, and JVM identity for database "
"identity is guaranteed by Hibernate. However, while the application might "
"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 ""
"<emphasis>個々の</emphasis><literal>Session</literal> に追加されたオブジェク"
"トにとって （すなわち、１つの <literal>Session</literal> のスコープの中で"
"は）、２つの概念は同じです。 データベース同一性とJVM同一性が一致することを、"
"Hibernateが保証します。 しかし、アプリケーションが２つの異なるセッションから "
"「同じ」（永続性識別子の）ビジネスオブジェクトに同時にアクセスする限り、 ２つ"
"のインスタンスは実際に（JVM識別子が）「異なり」ます。 楽観的アプローチによっ"
"て、（自動バージョニングの）フラッシュ／コミット時に コンフリクトが解決されま"
"す。"

#. Tag: para
#: transactions.xml:266
#, 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とデータベースに同時実行についての心配が残りま"
"す。 一方で、最高のスケーラビリティが提供されます。 なぜなら、１スレッドの作"
"業単位の中で一意性が保証されれば、 高価なロックや同期化が不要になるためで"
"す。 <literal>Session</literal> ごとに１つのスレッドを貼り付ける限り、 アプリ"
"ケーションはビジネスオブジェクトをsynchronizeする必要はありません。 "
"<literal>Session</literal> 内では、アプリケーションはオブジェクトを比較するた"
"めに、 <literal>==</literal> を安全に使用できます。"

#. Tag: para
#: transactions.xml:275
#, 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> を使うアプ"
"リケーションは、予期しない結果に遭遇します。 これは予期しない場所で起こりえま"
"す。 例えば、２つの分離インスタンスを同じ <literal>Set</literal> に putしたと"
"きなどです。 両方とも同じデータベース識別子を持ちます（すなわち、同じ行を表し"
"ます）。 しかし、分離状態のインスタンスのJVM識別子は当然保証されません。 開発"
"者は、永続性クラスの <literal>equals()</literal> と <literal>hashCode()</"
"literal> メソッドをオーバーライドし、オブジェクト等価性の概念を実装すべきで"
"す。 警告が１つあります。等価性の実装にデータベース識別子を使わないでくださ"
"い。 ユニークな（普通は不変の）属性の組み合わせであるビジネスキーを使ってくだ"
"さい。 もし、一時オブジェクトが永続化された場合、データベース識別子が変わりま"
"す。 一時オブジェクトを（通常分離インスタンスと共に） <literal>Set</literal> "
"に保持する場合、ハッシュコードが変わるということは、<literal>Set</literal> の"
"契約を破るということです。 ビジネスキーのための属性は、データベースの主キーほ"
"ど安定すべきではないです。 オブジェクトが同じ <literal>Set</literal> の中にい"
"る間だけ、安定を保証すべきです。 この問題のより徹底的な議論は、HibernateのWeb"
"サイトを参照してください。 また、これはHibernateの問題ではなく、単にJavaオブ"
"ジェクトの識別子や等価性を どのように実装すべきかということです。"

#. Tag: title
#: transactions.xml:296
#, no-c-format
msgid "Common issues"
msgstr "一般的な問題"

#. Tag: para
#: transactions.xml:298
#, 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:307
#, 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リクエスト、"
"セッションBean、Swingワーカーのように、 同時実行が可能なものが "
"<literal>Session</literal> インスタンスを共有すると、 競合状態を引き起こしま"
"す。 （後で議論する）<literal>HttpSession</literal> の中で Hibernate "
"<literal>Session</literal> を保持する場合、 HttpSessionへのアクセスを同期化す"
"ることを考慮すべきです。 さもなければ、ユーザーが十分早くリロードをクリックす"
"ると、 同時に走る２つのスレッドの中で、同じ <literal>Session</literal> が使わ"
"れます。"

#. Tag: para
#: transactions.xml:318
#, 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:330
#, 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> は永続（persistent）状態のすべてのオブジェクトを "
"キャッシュします（Hibernateは監視し、ダーティ状態かチェックします）。 これ"
"は、長い間セッションを開いたままにするか、 非常に多くのデータをロードし続ける"
"かした場合は、 OutOfMemoryExceptionが発生するまで無限に大きくなることを意味し"
"ます。 解決策の１つは、<literal>Session</literal> キャッシュを管理するため"
"に、 <literal>clear()</literal> か <literal>evict()</literal> を呼ぶことで"
"す。 しかし、大きなデータを処理する必要があるなら、 たぶんストアドプロシー"
"ジャを考慮するべきでしょう。 いくつかの解決策は、<xref linkend=\"batch\"/> で"
"紹介されています。 ユーザーセッションの間、<literal>Session</literal> を開い"
"たままにするということは、 データが新鮮でなくなる確率が高くなることを意味しま"
"す。"

#. Tag: title
#: transactions.xml:348
#, no-c-format
msgid "Database transaction demarcation"
msgstr "データベーストランザクション境界"

#. Tag: para
#: transactions.xml:350
#, no-c-format
msgid ""
"Datatabase (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:360
#, 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 ""
"J2EE環境に管理されていない状態 （すなわち、スタンドアロン、単純なWebやSwingア"
"プリケーション）でも、 管理された状態でも、Hibernateアプリケーションを実行で"
"きます。 管理されていない環境では、Hiberanteがデータベースのコネクションプー"
"ルを提供します。 アプリケーション開発者は、トランザクション境界を手動で設定し"
"なければなりません。 言い換えると、データベーストランザクションの開始、コミッ"
"ト、ロールバックを 開発者自身が設定する必要があるということです。 通常、管理"
"された環境では、コンテナ管理によるトランザクション（CMT）が提供されます。 例"
"えば、セッションBeanのデプロイメントディスクリプタで宣言的に定義し、 トランザ"
"クションを組み立てます。 プログラムによるトランザクション境界はもう必要ありま"
"せん。"

#. Tag: para
#: transactions.xml:370
#, no-c-format