HIBERNATE - Relational Persistence for Idiomatic Java
Hibernate Reference Documentation
Hibernateレファレンスドキュメンテーション
3.2.2
Table of Contents(コンテンツテーブル)
1. Introduction to Hibernate(Hibernateの紹介)
2. Architecture(アーキテクチャ)
2.1. Overview(概観)
2.2. Instance states(インスタンスの状態)
2.4. JCA Support(JCAサポート)
2.5. Contextual Sessions(コンテキストセッション)
Chapter 2. Architecture(第2章：アーキテクチャ)
2.1. Overview(概観)
A (very) high-level view of the Hibernate architecture:
Hibernateアーキテクチャの（非常に）高いレベルからのビュー：
This diagram shows Hibernate using the database and configuration data to provide persistence services (and persistent objects) to the application.
この図はHibernateが、アプリケーションに対して永続化サービス（と永続オブジェクト）を提供するために、データベースと設定データを使うことを示しています。
We would like to show a more detailed view of the runtime architecture. Unfortunately, Hibernate is flexible and supports several approaches. We will show the two extremes. The "lite" architecture has the application provide its own JDBC connections and manage its own transactions. This approach uses a minimal subset of Hibernate's APIs:
ここで実行時アーキテクチャのより詳細なビューをお見せしましょう。あいにく、Hibernateは柔軟であり、いろいろなアプローチをサポートしています。ここでは、2つの極端な例をお見せします。「軽い」アーキテクチャでは、アプリケーションが自前のJDBCコネクションを用意し、アプリケーション自身がトランザクションを管理します。この方法は、Hibernate APIの最小限のサブセットを使います：
The "full cream" architecture abstracts the application away from the underlying JDBC/JTA APIs and lets Hibernate take care of the details.
「重い」アーキテクチャは、アプリケーションから、その下に位置するJDBCやJTAのAPIを取り払って抽象化し、その詳細の面倒をHibernateに見させます。
Heres some definitions of the objects in the diagrams:
以下は、上の図に含まれるオブジェクトの定義です。
SessionFactory (org.hibernate.SessionFactory)
A threadsafe (immutable) cache of compiled mappings for a single database. A factory for Session and a client of ConnectionProvider. Might hold an optional (second-level) cache of data that is reusable between transactions, at a process- or cluster-level.
1つのデータベースに対するコンパイルされたマッピングのスレッドセーフな（更新不能の）キャッシュ。Sessionのファクトリであり、ConnectionProviderのクライアント。オプションとして、プロセスまたはクラスタレベルにおいて、トランザクション間で再利用可能なデータの（二次）キャッシュを持ちます。
Session (org.hibernate.Session)
A single-threaded, short-lived object representing a conversation between the application and the persistent store. Wraps a JDBC connection. Factory for Transaction. Holds a mandatory (first-level) cache of persistent objects, used when navigating the object graph or looking up objects by identifier.
アプリケーションと永続ストアとの対話を表す、シングルスレッドで短命のオブジェクト。JDBCコネクションをラップします。 Transactionのファクトリです。永続オブジェクトの必須の（一次）キャッシュを保持します。このキャッシュはオブジェクトグラフをナビゲーションする時や、識別子でオブジェクトを検索する時に使われます。
Persistent objects and collections(Persistent objectsとcollections)
Short-lived, single threaded objects containing persistent state and business function. These might be ordinary JavaBeans/POJOs, the only special thing about them is that they are currently associated with (exactly one) Session. As soon as the Session is closed, they will be detached and free to use in any application layer (e.g. directly as data transfer objects to and from presentation).
永続化状態とビジネスメソッドを持つ、短命でシングルスレッドのオブジェクト。これは通常のJavaBeans/POJOのこともありますが、特徴的なことは、その時点での（ただ1つの） Sessionと関連していることです。Sessionがクローズされるとすぐに、それらは切り離されて他のアプリケーション層から自由に使うことができます。（例えばデータ・トランスファ・オブジェクトとして、プレゼンテーション層から、またはプレゼンテーション層へ直接使用できます。）
Transient and detached objects and collections(Transientとdetached objectsとcollections)
Instances of persistent classes that are not currently associated with a Session. They may have been instantiated by the application and not (yet) persisted or they may have been instantiated by a closed Session.
現時点では Sessionと関連していない、永続クラスのインスタンス。すでにアプリケーション側でインスタンス化されていて、まだ永続化されていないか、クローズされたSessionでインスタンス化されたかのどちらかです。
Transaction (org.hibernate.Transaction)
(Optional) A single-threaded, short-lived object used by the application to specify atomic units of work. Abstracts application from underlying JDBC, JTA or CORBA transaction. A Session might span several Transactions in some cases. However, transaction demarcation, either using the underlying API or Transaction, is never optional!
(オプション)原子性を持つ作業単位(Unit of Work)を指定するために、アプリケーションが使用する、シングルスレッドで短命なオブジェクト。下に位置するJDBC、JTA、CORBAトランザクションからアプリケーションを抽象化します。 Sessionは、時にはいくつかのTransactionをまたがるかもしれません。しかし、下の層のAPIを使うにせよ、Transactionを使うにせよ、トランザクション境界を設定することは、決してオプションではありません。
ConnectionProvider (org.hibernate.connection.ConnectionProvider)
(Optional) A factory for (and pool of) JDBC connections. Abstracts application from underlying Datasource or DriverManager. Not exposed to application, but can be extended/implemented by the developer.
(オプション)JDBCコネクション（とそのプール）のファクトリ。下の層に位置するDatasourceやDriverManagerからアプリケーションを抽象化します。アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
TransactionFactory (org.hibernate.TransactionFactory)
(Optional) A factory for Transaction instances. Not exposed to the application, but can be extended/implemented by the developer.
(オプション) Transactionインスタンスのファクトリ。アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
Extension Interfaces
Hibernate offers many optional extension interfaces you can implement to customize the behavior of your persistence layer. See the API documentation for details.
Hibernateは、永続層の振る舞いをカスタマイズするために、多くのオプション拡張インタフェースを用意しています。詳細はAPIドキュメントを参照してください。
Given a "lite" architecture, the application bypasses the Transaction/TransactionFactoryand/or ConnectionProvider APIs to talk to JTA or JDBC directly.
「軽い」アーキテクチャでは、アプリケーションは直接JTAやJDBCと対話するために、Transactionや TransactionFactoryやConnectionProviderをバイパスします。
2.2. Instance states(インスタンスの状態)
An instance of a persistent classes may be in one of three different states, which are defined with respect to a persistence context. The Hibernate Session object is the persistence context:
永続クラスのインスタンスは、次の３つの異なる状態のどれかになります。それは、永続コンテキストによって決まります。Hibernateの Sessionオブジェクトが、永続コンテキストになります。
transient
The instance is not, and has never been associated with any persistence context. It has no persistent identity (primary key value).
この状態のインスタンスは、現在もそして過去においても、永続コンテキストに関連づいていません。また、永続ID（主キーの値）を持っていません。
persistent
The instance is currently associated with a persistence context. It has a persistent identity (primary key value) and, perhaps, a corresponding row in the database. For a particular persistence context, Hibernate guarantees that persistent identity is equivalent to Java identity (in-memory location of the object).
この状態のインスタンスは、その時点で永続コンテキストに関連づいています。また、永続ID（主キーの値）を持ち、たいていはデータベースに対応する行を持っているでしょう。個々の永続コンテキストのなかでは、永続IDがJavaのID（オブジェクトのメモリ上の位置）と同じであることをHibernateが保証します。
detached
The instance was once associated with a persistence context, but that context was closed, or the instance was serialized to another process. It has a persistent identity and, perhaps, a corrsponding row in the database. For detached instances, Hibernate makes no guarantees about the relationship between persistent identity and Java identity.
この状態のインスタンスは、かつて永続コンテキストに関連づけられたが、そのコンテキストがクローズされたか、あるいは、他のプロセスにそのインスタンスがシリアライズされたかです。このインスタンスは、永続IDを持ち、たいていはデータベースに対応する行を持っているでしょう。分離インスタンスに対しては、永続IDとJavaのIDとの関連は、Hibernateが保証しません。
2.3. JMX Integration(JMXとの統合)
JMX is the J2EE standard for management of Java components. Hibernate may be managed via a JMX standard service. We provide an MBean implementation in the distribution, org.hibernate.jmx.HibernateService.
JMXはJavaコンポーネント管理のJ2EE標準です。JMX標準サービスを通して、Hibernateは管理されます。ディストリビューションの中に org.hibernate.jmx.HibernateServiceというMBean実装を用意しています。
For an example how to deploy Hibernate as a JMX service on the JBoss Application Server, please see the JBoss User Guide. On JBoss AS, you also get these benefits if you deploy using JMX:
JBoss アプリケーションサーバー上にHibernateをJMXサービスとしてデプロイする方法の例としては、JBoss ユーザガイドを参照してください。 JBoss アプリケーションサーバーにおいて、JMXを使ってデプロイすると、次のメリットが得られます。
? Session Management: The Hibernate Session's lifecycle can be automatically bound to the scope of a JTA transaction. This means you no longer have to manually open and close the Session, this becomes the job of a JBoss EJB interceptor. You also don't have to worry about transaction demarcation in your code anymore (unless you'd like to write a portable persistence layer of course, use the optional HibernateTransaction API for this). You call the HibernateContext to access a Session.
セッション管理:Hibernateの Sessionのライフサイクルは、自動的にJTAトランザクションのスコープに結びつけられます。これは、もはや手動でSessionをオープンしたり、クローズしたりする必要がないことを意味します。これは、JBoss EJB インターセプタの仕事になります。また、コードのどこでトランザクション境界を設定するかについて、もはや悩む必要がありません（もちろん移植可能な永続層を書かかなくていいのならば、オプションのHibernateの Transactionを使用してください。）Sessionにアクセスするためには、 HibernateContextをコールしてください。
? HAR deployment: Usually you deploy the Hibernate JMX service using a JBoss service deployment descriptor (in an EAR and/or SAR file), it supports all the usual configuration options of a Hibernate SessionFactory. However, you still have to name all your mapping files in the deployment descriptor. If you decide to use the optional HAR deployment, JBoss will automatically detect all mapping files in your HAR file.
HAR デプロイ：通常、(EAR または SAR ファイルにある）JBoss サービスデプロイメントディスクリプタを使って、Hibernate JMX サービスをデプロイします。それは、Hibernateの SessionFactoryの全ての一般的な設定オプションをサポートします。しかし依然としてデプロイメントディスクリプタのなかにすべてのマッピングファイルの名前を挙げる必要があります。もし、オプションのHARデプロイメントを使うことを決めたなら、JBossは自動的にHARファイルのなかの全てのマッピングファイルを検出します。
Consult the JBoss AS user guide for more information about these options.
これらのオプションについての詳細な情報は、JBossアプリケーションサーバユーザガイドを参考にしてください。
Another feature available as a JMX service are runtime Hibernate statistics. SeeSection 3.4.6, "Hibernate statistics".
JMXサービスとして利用可能な他の機能に、Hibernate実行時統計情報があります。Section 3.4.6, "Hibernate statistics"を見てください。
2.4. JCA Support(JCAサポート)
Hibernate may also be configured as a JCA connector. Please see the website for more details. Please note that Hibernate JCA support is still considered experimental.
Hibernate は JCA コネクタとしても設定できます。詳細については、Webサイトを見てください。Hibernate JCA サポートは、今のところ実験段階として考えられていることに注意してください。
2.5. Contextual Sessions(コンテキスト上のセッション)
Most applications using Hibernate need some form of "contextual" sessions, where a given session is in effect throughout the scope of a given context. However, across applications the definition of what constitutes a context is typically different; and different contexts define different scopes to the notion of current. Applications using Hibernate prior to version 3.0 tended to utilize either home-grown ThreadLocal-based contextual sessions, helper classes such as HibernateUtil, or utilized third-party frameworks (such as Spring or Pico) which provided proxy/interception-based contextual sessions.
Hibernate を使ったアプリケーションは、ほとんど、なんらかの形で"コンテキスト上の"セッションが必要になります。「コンテキスト上のセッション」は、特定のコンテキストのスコープのなかで有効なセッションのことです。しかし、通常アプリケーションごとにコンテキストを構成するものの定義は異なります。しかも、異なる複数のコンテキストは、現時点に対して異なるスコープを定義します。バージョン3.0より前の Hibernateでは、自作の ThreadLocalベースの「コンテキスト上のセッション」を利用するか、HibernateUtilのようなヘルパークラスを利用するか、proxy/interception ベースの「コンテキスト上のセッション」を提供する（Spring や Pico のような）サードパーティのフレームワークを利用するかのいずれかでした。
Starting with version 3.0.1, Hibernate added the SessionFactory.getCurrentSession()method. Initially, this assumed usage of JTA transactions, where the JTA transaction defined both the scope and context of a current session. The Hibernate team maintains that, given the maturity of the numerous stand-alone JTA TransactionManagerimplementations out there, most (if not all) applications should be using JTA transaction management whether or not they are deployed into a J2EE container. Based on that, theJTA-based contextual sessions is all you should ever need to use.
バージョン 3.0.1 から、Hibernate には SessionFactory.getCurrentSession()が加わりました。 これは、 JTAトランザクションの使用を前提にしています。JTAトランザクションは、現在のセッションのスコープとコンテキストの両方を定義します。Hibernate チームは、次のことを主張します。巨大なスタンドアロンの JTA TransactionManager実装が成熟したら、J2EEコンテナ上にデプロイされるかどうかにかかわらず、ほとんどの（すべてとは言わないが）アプリケーションが、JTAトランザクション管理を使用すべきであると。この考えに基づくと、 JTAベースの「コンテキスト上のセッション」を使うしかないでしょう。
However, as of version 3.1, the processing behind SessionFactory.getCurrentSession() is now pluggable. To that end, a new extension interface (org.hibernate.context.CurrentSessionContext) and a new configuration parameter (hibernate.current_session_context_class) have been added to allow pluggability of the scope and context of defining current sessions.
しかし、バージョン 3.1 からは、 SessionFactory.getCurrentSession()の後の処理が、プラガブルになりました。これを受けて、現在のセッションを定義するスコープとコンテキストのプラガビリティを可能にするために、新しい拡張インタフェース ( org.hibernate.context.CurrentSessionContext) と新しい構成パラメータ ( hibernate.current_session_context_class) が追加されました。
See the Javadocs for the org.hibernate.context.CurrentSessionContext interface for a detailed discussion of its contract. It defines a single method, currentSession(), by which the implementation is responsible for tracking the current contextual session. Out-of-the-box, Hibernate comes with three implementations of this interface.
org.hibernate.context.CurrentSessionContextインタフェースの規約についての詳細な内容は Javadoc を参照してください。それには、 currentSession()という1つのメソッドが定義されており、その実装は、現在の「コンテキスト上のセッション」を追跡することに責任を持ちます。そのまま使えるように、Hibernateはこのインタフェースの実装を2つ提供しています。
? org.hibernate.context.JTASessionContext - current sessions are tracked and scoped by a JTA transaction. The processing here is exactly the same as in the older JTA-only approach. See the Javadocs for details.
org.hibernate.context.JTASessionContext- JTAトランザクションによって、現在のセッションが追跡され、スコープを決められます。この処理は、古いJTAだけのアプローチとまったく同じです。詳細はJavadocを参照してください。
? org.hibernate.context.ThreadLocalSessionContext - current sessions are tracked by thread of execution. Again, see the Javadocs for details.
org.hibernate.context.ThreadLocalSessionContext-スレッドの実行によって、現在のセッションが追跡されます。詳細はJavadocを参照してください。
? org.hibernate.context.ManagedSessionContext - current sessions are tracked by thread of execution. However, you are responsible to bind and unbind a Session instance with static methods on this class, it does never open, flush, or close a Session.
org.hibernate.context.ManagedSessionContext- スレッドの実行によって、現在のセッションが追跡されます。しかし、このクラスのstaticメソッドで Sessionインスタンスをバインド/アンバインドする責任はあなたにあります。これは決して Sessionをオープン、フラッシュ、クローズしません。
The first two implementations provide a "one session - one database transaction" programming model, also known and used as session-per-request. The beginning and end of a Hibernate session is defined by the duration of a database transaction. If you use programatic transaction demarcation in plain JSE without JTA, you are adviced to use the Hibernate Transaction API to hide the underlying transaction system from your code. If you use JTA, use the JTA interfaces to demarcate transactions. If you execute in an EJB container that supports CMT, transaction boundaries are defined declaratively and you don't need any transaction or session demarcation operations in your code. Refer to Chapter 11, Transactions And Concurrency for more information and code examples.
始めの2つの実装は、"1セッション - 1データベーストランザクション" プログラミングモデルを提供します。これはリクエストごとのセッション（session-per-request）としても知られており、使われています。Hibernate セッションの開始と終了は、データベーストランザクションの期間で決まります。JTAを使わない普通のJSEで、プログラム上のトランザクション境界設定を行うなら、コードから基礎のトランザクションシステムを隠蔽するために、Hibernate TransactionAPIを使うとよいでしょう。JTAを使うなら、トランザクションの境界設定には、JTAインタフェースを使ってください。CMTをサポートするEJBコンテナで実行するつもりなら、トランザクション境界は宣言的に定義できるため、コード上でトランザクションやセッションの境界を設定する必要はありません。さらに詳細な情報やコードの例は、Chapter 11, Transactions And Concurrencyを参照してください。
The hibernate.current_session_context_class configuration parameter defines whichorg.hibernate.context.CurrentSessionContext implementation should be used. Note that for backwards compatibility, if this config param is not set but aorg.hibernate.transaction.TransactionManagerLookup is configured, Hibernate will use the org.hibernate.context.JTASessionContext. Typically, the value of this parameter would just name the implementation class to use; for the three out-of-the-box implementations, however, there are two corresponding short names, "jta", "thread", and "managed".
hibernate.current_session_context_class設定パラメータは、org.hibernate.context.CurrentSessionContextのどの実装を使うかを指定します。下位互換性のため、このパラメータが設定されずorg.hibernate.transaction.TransactionManagerLookupが設定されていた場合、Hibernateは org.hibernate.context.JTASessionContextを使うことに注意してください。通常このパラメータの値には、3つの実装の中から使用する実装クラスの名前を直接指定します。しかし、"jta", "thread", "managed"というそれぞれの省略名も用意されています。
No comments:
Post a Comment