hibernate

This package defines the central Hibernate APIs.

This package defines "actions" that are scheduled for asycnchronous execution by the event listeners.

This package defines the API for plugging in bytecode libraries for usage by Hibernate. Hibernate uses these bytecode libraries in three scenarios:

1. Reflection optimization - to speed up the performance of POJO entity and component conctruction and field/property access
2. Proxy generation - runtime building of proxies used for deferred loading of lazy entities
3. Field-level interception - build-time instrumentation of entity classes for the purpose of intercepting field-level access (read/write) for both lazy loading and dirty tracking.

Currently, both CGLIB and Javassist are supported out-of-the-box.

Note that for field-level interception, simply plugging in a new {@link BytecodeProvider} is not enough for Hibernate to be able to recognize new providers. You would additionally need to make appropriate code changes to the {@link org.hibernate.intercept.Helper} class. This is because the detection of these enhanced classes is needed in a static environment (i.e. outside the scope of any {@link org.hibernate.SessionFactory}.

Note that in the current form the ability to specify a different bytecode provider is actually considered a global settings (global to the JVM).

This package defines APIs/SPIs and implementations for the Hibernate second-level cache.

The legacy (and now deprecated) approach to caching is defined by the {@link org.hibernate.cache.CacheProvider} and {@link org.hibernate.cache.Cache} interfaces as well as the {@link org.hibernate.cache.CacheConcurrencyStrategy} interface along with the various implementations of all these interfaces. In that scheme, a {@link org.hibernate.cache.CacheProvider} defined how to configure and perform lifecycle operations in regards to a particular underlying caching library; it also defined how to build {@link org.hibernate.cache.Cache} instances which in turn defined how to access the "regions" of the underlying cache instance. For entity and collection data cache regions, {@link org.hibernate.cache.CacheConcurrencyStrategy} wrapped access to those cache regions to apply transactional/concurrent access semantics.

The improved approach is based on {@link org.hibernate.cache.RegionFactory}, the various {@link org.hibernate.cache.Region} specializations and the two access strategies contracts ({@link org.hibernate.cache.access.EntityRegionAccessStrategy} and {@link org.hibernate.cache.access.CollectionRegionAccessStrategy}). The general approach here is that {@link org.hibernate.cache.RegionFactory} defined how to configure and perform lifecycle operations in regards to a particular underlying caching library (or libraries). {@link org.hibernate.cache.RegionFactory} also defines how to build specialized {@link org.hibernate.cache.Region} instances based on the type of data we will be storing in that given region. The fact that {@link org.hibernate.cache.RegionFactory} is asked to build specialized regions (as opposed to just general access) is the first improvement over the legacy scheme. The second improvement is the fact that the regions (well the ones like entity and collection regions that are responsible for storing {@link org.hibernate.cache.TransactionalDataRegion transactional} data) are asked to build their own access strategies (see {@link org.hibernate.cache.EntityRegion#buildAccessStrategy} and {@link org.hibernate.cache.CollectionRegion#buildAccessStrategy}).

Defines contracts for transactional and concurrent access to cached {@link org.hibernate.cache.access.EntityRegionAccessStrategy entity} and {@link org.hibernate.cache.access.CollectionRegionAccessStrategy collection} data. Transactions pass in a timestamp indicating transaction start time which is then used to protect against concurrent access (exactly how that occurs is based on the actual access-strategy impl used). Two different implementation patterns are provided for.

• A transaction-aware cache implementation might be wrapped by a synchronous access strategy, where updates to the cache are written to the cache inside the transaction.
• A non-transaction-aware cache would be wrapped by an asynchronous access strategy, where items are merely "soft locked" during the transaction and then updated during the "after transaction completion" phase; the soft lock is not an actual lock on the database row - only upon the cached representation of the item.

Note that, for an asynchronous cache, cache invalidation must be a two step process (lock->unlock or lock->afterUpdate), since this is the only way to guarantee consistency with the database for a nontransactional cache implementation. For a synchronous cache, cache invalidation is a single step process (evict or update). Hence, these contracts ({@link org.hibernate.cache.access.EntityRegionAcessStrategy} and {@link org.hibernate.cache.access.CollectionRegionAccessStrategy}) define a three step process to cater for both models (see the individual contracts for details).

Note that query result caching does not go through an access strategy; those caches are managed directly against the underlying {@link org.hibernate.cache.QueryResultsRegion}.

This package defines formats for disassembled state kept in the second level cache.

This package defines APIs for configuring Hibernate, and classes for building the Hibernate configuration-time metamodel.

This package implements backward-compatibility with Hibernate 2.1 APIs now deprecated in Hibernate3.

This package defines a framework for collection wrappers.

This package abstracts the mechanism for obtaining a JDBC connection.

A concrete implementation of ConnectionProvider may be selected by specifying hibernate.connection.provider_class.

A framework for defining restriction criteria and order criteria.

This package abstracts the SQL dialect of the underlying database.

A concrete Dialect may be specifed using hibernate.dialect.

A framework for defining database-specific SQL functions that are available via the dialect.

This package contains classes that are "shared" by other packages, and implementations of some key algorithms.

This package defines an event framework for Hibernate.

This package defines a default set of event listeners that implements the default behaviors of Hibernate.

This package is a fork of Apache commons-lang nestable exceptions.

This package defines the interface between Hibernate and the HQL query parser implementation (to allow switching between the 2.x and 3.0 HQL parsers).

An ANTLR-based parser for Hibernate Query Language.

Classes in this package extend the ANTLR-generated parser classes.

This package contains the Hibernate 2.x query parser which is being end-of-lifed.

This package contains internal implementation classes for the main API interfaces.

This package contains implementations of the central Hibernate APIs, especially the Hibernate session.

This package implements an interception mechanism for lazy property fetching, based on CGLIB bytecode instrumentation.

This package abstracts the mechanism for dispatching SQL statements to the database, and implements interaction with JDBC.

Concrete implementations of the Batcher interface may be selected by specifying hibernate.jdbc.factory_class.

This package exposes a Hibernate instance via JMX.

HibernateService allows configuration and management of the Hibernate runtime. StatisticsService reports information that might be useful for performance tuning.

This package defines functionality for processing JDBC result sets and returning complex graphs of persistent objects.

Subclasses of Loader define a particular query mechanism.

This package defines collection initializers

This package defines the criteria query compiler and loader

This package defines a framework for custom loaders that accept handwritten SQL

This package defines entity loaders

This package defines a loader for the AST-based query parser

This package defines dummy and wrapper implementations of java.sql.Clob and java.sql.Blob.

This package defines the Hibernate configuration-time metamodel.

This package defines an API for accessing the Hibernate runtime metamodel.

A persister defines a mapping strategy for a collection or entity.

This package abstracts the persistence mechanism for collections.

Concrete implementations of CollectionPersister define strategies for persistence of particular collection roles. Collection persisters may optionally implement QueryableCollection if they should be queryable using HQL or loaded using OuterJoinLoader.

This package abstracts persistence mechanisms for entities, and defines the Hibernate runtime metamodel.

Strategies for persisting entities implement the EntityPersister interface. Optionally, they may implement certain additional interfaces that define contracts with various loaders. Concrete implementations in this package define the built-in inheritance mapping strategies.

Classes for pretty printing things for exception and log messages.

This package abstracts the notion of a "property" of an entity. Support for JavaBean properties and Map elements is included.

This package defines a framework for lazy-initializing entity proxies.

Declarative security for CRUD operations on entities.

This package defines helper classes for rendering SQL fragments and SQL statements.

This package exposes statistics about a running Hibernate instance to the application.

Demonstration of different ways to use Hibernate to represent your domain model as a series of JDK dynamic proxies. We map the interfaces and then use one of two approaches to get Hibernate to recognize these proxies as domain entities. Really this is demonstrating various "entity representation" capabilities built in to Hibernate3.

First we use an interceptor-based approach where we use a custom Interceptor implementation for interpret incoming proxies (and resolve them to the correct mappings) and to help Hibernate instantiate these proxy instances. This is the quick-and-dirty approach. It is fully expected that this approach will encounter certain limitations.

Next we explore the notion of a Tuplizer and plug in custom Tuplizers to help achieve the same results. Currently, Tuplizers do not have a chance to influence the resolution of entity-name given a potential entity, so we also use an Interceptor here and supply its getEntityName() impl. This is simply so we do not need to supply the entity name explicitly to the Hibernate Session calls.

Tests for any JPA-specific behavior for which we need to ensure compliance.

Defines a simplified JTA TransactionManager and transactional connection pool designed for use in test suite and simple usage scenarios. For example, it is assumed that there is only ever a single transaction active at a given time. Also, the only 'resource' that the transaction tracks is a single JDBC connection.

The hbm2ddl tool.

The instrument tool for adding field-interception hooks to persistent classes using built-time bytecode processing. Use this tool only if you wish to take advantage of lazy property fetching (the <lazy> mapping element).

This package abstracts the underlying transaction mechanism (JTA or JDBC) and provides strategies for obtaining application server TransactionManagers.

Defines strategies for post-processing criteria query result sets into a form convenient to the application.

This package defines a runtime metamodel for entities at the object level and abstracts the differences between the various entity modes. It is unaware of mappings to the database.

(This package is still undergoing maturation and will change over the next few months.)

A Hibernate Type is a strategy for mapping a Java property type to a JDBC type or types.

Interfaces for user-defined custom types.

Utility classes.