[HHH-2930] typos in documentation: datatabase, is send, etc
git-svn-id: https://svn.jboss.org/repos/hibernate/core/trunk@14585 1b8cb986-b30d-0410-93ca-fae66ebed9b2
This commit is contained in:
parent
7b727315c5
commit
dc61408401
|
@ -215,7 +215,7 @@
|
|||
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.
|
||||
identity and, perhaps, a corresponding row in the database.
|
||||
For detached instances, Hibernate makes no guarantees
|
||||
about the relationship between persistent identity and
|
||||
Java identity.
|
||||
|
@ -348,7 +348,7 @@
|
|||
The first two implementations provide a "one session - one database transaction" programming
|
||||
model, also known and used as <emphasis>session-per-request</emphasis>. 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
|
||||
If you use programmatic transaction demarcation in plain JSE without JTA, you are advised to
|
||||
use the Hibernate <literal>Transaction</literal> 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
|
||||
|
|
|
@ -522,7 +522,7 @@ Cat fritz = (Cat) iter.next();]]></programlisting>
|
|||
<para>
|
||||
You may also enable batch fetching of collections. For example, if each <literal>Person</literal> has
|
||||
a lazy collection of <literal>Cat</literal>s, and 10 persons are currently loaded in the
|
||||
<literal>Sesssion</literal>, iterating through all persons will generate 10 <literal>SELECT</literal>s,
|
||||
<literal>Session</literal>, iterating through all persons will generate 10 <literal>SELECT</literal>s,
|
||||
one for every call to <literal>getCats()</literal>. If you enable batch fetching for the
|
||||
<literal>cats</literal> collection in the mapping of <literal>Person</literal>, Hibernate can pre-fetch
|
||||
collections:
|
||||
|
@ -615,7 +615,7 @@ Cat fritz = (Cat) iter.next();]]></programlisting>
|
|||
A different (better?) way to avoid unnecessary column reads, at least for
|
||||
read-only transactions is to use the projection features of HQL or Criteria
|
||||
queries. This avoids the need for buildtime bytecode processing and is
|
||||
certainly a prefered solution.
|
||||
certainly a preferred solution.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -760,7 +760,7 @@ Cat fritz = (Cat) iter.next();]]></programlisting>
|
|||
</programlistingco>
|
||||
|
||||
<para>
|
||||
Alternatively (preferrably?), you may specify <literal><class-cache></literal> and
|
||||
Alternatively (preferably?), you may specify <literal><class-cache></literal> and
|
||||
<literal><collection-cache></literal> elements in <literal>hibernate.cfg.xml</literal>.
|
||||
</para>
|
||||
|
||||
|
@ -1124,7 +1124,7 @@ hibernate.cache.use_structured_entries true]]></programlisting>
|
|||
Sets have a primary key consisting of <literal><key></literal> and element
|
||||
columns. This may be less efficient for some types of collection element, particularly
|
||||
composite elements or large text or binary fields; the database may not be able to index
|
||||
a complex primary key as efficently. On the other hand, for one to many or many to many
|
||||
a complex primary key as efficiently. On the other hand, for one to many or many to many
|
||||
associations, particularly in the case of synthetic identifiers, it is likely to be just
|
||||
as efficient. (Side-note: if you want <literal>SchemaExport</literal> to actually create
|
||||
the primary key of a <literal><set></literal> for you, you must declare all columns
|
||||
|
@ -1330,7 +1330,7 @@ server.registerMBean(stats, on); // Register the MBean on the server]]></program
|
|||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Statistics can be reset programatically using the <literal>clear()</literal> method.
|
||||
Statistics can be reset programmatically using the <literal>clear()</literal> method.
|
||||
A summary can be sent to a logger (info level) using the <literal>logSummary()</literal>
|
||||
method.
|
||||
</para>
|
||||
|
@ -1367,7 +1367,7 @@ server.registerMBean(stats, on); // Register the MBean on the server]]></program
|
|||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
For exampl,e you can check the cache hit, miss, and put ratio of entities, collections
|
||||
For example, you can check the cache hit, miss, and put ratio of entities, collections
|
||||
and queries, and the average time a query needs. Beware that the number of milliseconds
|
||||
is subject to approximation in Java. Hibernate is tied to the JVM precision, on some
|
||||
platforms this might even only be accurate to 10 seconds.
|
||||
|
|
|
@ -59,7 +59,7 @@ sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").list();
|
|||
</itemizedlist>
|
||||
|
||||
<para>This will still return Object arrays, but now it will not use
|
||||
<literal>ResultSetMetdata</literal> but will instead explicitly get the
|
||||
<literal>ResultSetMetadata</literal> but will instead explicitly get the
|
||||
ID, NAME and BIRTHDATE column as respectively a Long, String and a Short
|
||||
from the underlying resultset. This also means that only these three
|
||||
columns will be returned, even though the query is using
|
||||
|
@ -181,7 +181,7 @@ sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").addEntity(Cat.class)
|
|||
row, a cat and its mother. This will fail since there is a conflict of
|
||||
names since they are mapped to the same column names and on some
|
||||
databases the returned column aliases will most likely be on the form
|
||||
"c.ID", "c.NAME", etc. which are not equal to the columns specificed in
|
||||
"c.ID", "c.NAME", etc. which are not equal to the columns specified in
|
||||
the mappings ("ID" and "NAME").</para>
|
||||
|
||||
<para>The following form is not vulnerable to column name
|
||||
|
@ -206,7 +206,7 @@ sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").addEntity(Cat.class)
|
|||
</itemizedlist>
|
||||
|
||||
<para>The {cat.*} and {mother.*} notation used above is a shorthand for
|
||||
"all properties". Alternatively, you may list the columns explicity, but
|
||||
"all properties". Alternatively, you may list the columns explicitly, but
|
||||
even in this case we let Hibernate inject the SQL column aliases for
|
||||
each property. The placeholder for a column alias is just the property
|
||||
name qualified by the table alias. In the following example, we retrieve
|
||||
|
@ -450,7 +450,7 @@ List pusList = query.setString("name", "Pus%").list(); ]]></programlist
|
|||
</sql-query>]]></programlisting>
|
||||
|
||||
<para>You can externalize the resultset mapping informations in a
|
||||
<literal><resultset></literal> element to either reuse them accross
|
||||
<literal><resultset></literal> element to either reuse them across
|
||||
several named queries or through the
|
||||
<literal>setResultSetMapping()</literal> API.</para>
|
||||
|
||||
|
|
|
@ -87,7 +87,7 @@
|
|||
<para>
|
||||
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
|
||||
is sent 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
|
||||
|
@ -100,7 +100,7 @@
|
|||
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
|
||||
before the response is sent 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
|
||||
|
@ -174,7 +174,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Clearly, we have to use several database transactions to implement the converastion.
|
||||
Clearly, we have to use several database transactions to implement the conversation.
|
||||
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
|
||||
|
@ -189,7 +189,7 @@
|
|||
<para>
|
||||
<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
|
||||
if a concurrent modification occurred during user think time. Usually
|
||||
we only check at the end of the conversation.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -212,7 +212,7 @@
|
|||
<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.
|
||||
not allowed to be flushed automatically, but explicitly.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
@ -348,7 +348,7 @@
|
|||
<title>Database transaction demarcation</title>
|
||||
|
||||
<para>
|
||||
Datatabase (or system) transaction boundaries are always necessary. No communication with
|
||||
Database (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
|
||||
|
@ -370,7 +370,7 @@
|
|||
<para>
|
||||
However, it is often desirable to keep your persistence layer portable between non-managed
|
||||
resource-local environments, and systems that can rely on JTA but use BMT instead of CMT.
|
||||
In both cases you'd use programmatic transaction demaracation. Hibernate offers a wrapper
|
||||
In both cases you'd use programmatic transaction demarcation. Hibernate offers a wrapper
|
||||
API called <literal>Transaction</literal> that translates into the native transaction system of
|
||||
your deployment environment. This API is actually optional, but we strongly encourage its use
|
||||
unless you are in a CMT session bean.
|
||||
|
@ -544,7 +544,7 @@ catch (RuntimeException e) {
|
|||
}]]></programlisting>
|
||||
|
||||
<para>
|
||||
With CMT, transaction demarcation is done in session bean deployment descriptors, not programatically,
|
||||
With CMT, transaction demarcation is done in session bean deployment descriptors, not programmatically,
|
||||
hence, the code is reduced to:
|
||||
</para>
|
||||
|
||||
|
@ -569,7 +569,7 @@ catch (RuntimeException e) {
|
|||
in a CMT session bean, when you configure Hibernate's transaction factory. Remember to also set
|
||||
<literal>hibernate.transaction.manager_lookup_class</literal>. Furthermore, make sure
|
||||
that your <literal>hibernate.current_session_context_class</literal> is either unset (backwards
|
||||
compatiblity), or set to <literal>"jta"</literal>.
|
||||
compatibility), or set to <literal>"jta"</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -580,7 +580,7 @@ catch (RuntimeException e) {
|
|||
<literal>Iterator</literal> instances returned by <literal>scroll()</literal> or
|
||||
<literal>iterate()</literal>. You <emphasis>must</emphasis> release the underlying database
|
||||
cursor by calling <literal>ScrollableResults.close()</literal> or
|
||||
<literal>Hibernate.close(Iterator)</literal> explicity from a <literal>finally</literal>
|
||||
<literal>Hibernate.close(Iterator)</literal> explicitly from a <literal>finally</literal>
|
||||
block. (Of course, most applications can easily avoid using <literal>scroll()</literal> or
|
||||
<literal>iterate()</literal> at all from the JTA or CMT code.)
|
||||
</para>
|
||||
|
@ -615,8 +615,8 @@ catch (RuntimeException e) {
|
|||
|
||||
<para>
|
||||
Hibernate wraps <literal>SQLException</literal>s thrown while interacting with the database
|
||||
in a <literal>JDBCException</literal>. In fact, Hibernate will attempt to convert the eexception
|
||||
into a more meningful subclass of <literal>JDBCException</literal>. The underlying
|
||||
in a <literal>JDBCException</literal>. In fact, Hibernate will attempt to convert the exception
|
||||
into a more meaningful subclass of <literal>JDBCException</literal>. The underlying
|
||||
<literal>SQLException</literal> is always available via <literal>JDBCException.getCause()</literal>.
|
||||
Hibernate converts the <literal>SQLException</literal> into an appropriate
|
||||
<literal>JDBCException</literal> subclass using the <literal>SQLExceptionConverter</literal>
|
||||
|
@ -674,7 +674,7 @@ catch (RuntimeException e) {
|
|||
Hibernate can at least control data access operations, ensuring that database
|
||||
level deadlocks and queries with huge result sets are limited by a defined
|
||||
timeout. In a managed environment, Hibernate can delegate transaction timeout
|
||||
to JTA. This functioanlity is abstracted by the Hibernate
|
||||
to JTA. This functionality is abstracted by the Hibernate
|
||||
<literal>Transaction</literal> object.
|
||||
</para>
|
||||
|
||||
|
@ -762,7 +762,7 @@ session.close();]]></programlisting>
|
|||
<para>
|
||||
Clearly, manual version checking is only feasible in very trivial circumstances
|
||||
and not practical for most applications. Often not only single instances, but
|
||||
complete graphs of modified ojects have to be checked. Hibernate offers automatic
|
||||
complete graphs of modified objects have to be checked. Hibernate offers automatic
|
||||
version checking with either an extended <literal>Session</literal> or detached instances
|
||||
as the design paradigm.
|
||||
</para>
|
||||
|
@ -866,7 +866,7 @@ session.close();]]></programlisting>
|
|||
|
||||
<para>
|
||||
Again, Hibernate will check instance versions during flush, throwing an
|
||||
exception if conflicting updates occured.
|
||||
exception if conflicting updates occurred.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -893,7 +893,7 @@ session.close();]]></programlisting>
|
|||
even timestamps. In both cases, versioning can't rely on a particular column in a table.
|
||||
To force a version check without a version or timestamp property mapping, with a
|
||||
comparison of the state of all fields in a row, turn on <literal>optimistic-lock="all"</literal>
|
||||
in the <literal><class></literal> mapping. Note that this concepetually only works
|
||||
in the <literal><class></literal> mapping. Note that this conceptually only works
|
||||
if Hibernate can compare the old and new state, i.e. if you use a single long
|
||||
<literal>Session</literal> and not session-per-request-with-detached-objects.
|
||||
</para>
|
||||
|
@ -909,7 +909,7 @@ session.close();]]></programlisting>
|
|||
comparison, Hibernate uses a single <literal>UPDATE</literal> statement (with an
|
||||
appropriate <literal>WHERE</literal> clause) per entity to execute the version check
|
||||
and update the information. If you use transitive persistence to cascade reattachment
|
||||
to associated entities, Hibernate might execute uneccessary updates. This is usually
|
||||
to associated entities, Hibernate might execute unnecessary updates. This is usually
|
||||
not a problem, but <emphasis>on update</emphasis> triggers in the database might be
|
||||
executed even when no changes have been made to detached instances. You can customize
|
||||
this behavior by setting <literal>select-before-update="true"</literal> in the
|
||||
|
@ -925,7 +925,7 @@ session.close();]]></programlisting>
|
|||
<title>Pessimistic Locking</title>
|
||||
|
||||
<para>
|
||||
It is not intended that users spend much time worring about locking strategies. Its usually
|
||||
It is not intended that users spend much time worrying about locking strategies. It's usually
|
||||
enough to specify an isolation level for the JDBC connections and then simply let the
|
||||
database do all the work. However, advanced users may sometimes wish to obtain
|
||||
exclusive pessimistic locks, or re-obtain locks at the start of a new transaction.
|
||||
|
@ -1042,7 +1042,7 @@ session.close();]]></programlisting>
|
|||
<listitem>
|
||||
<para>
|
||||
<literal>ON_CLOSE</literal> - is essentially the legacy behavior described above. The
|
||||
Hibernate session obatins a connection when it first needs to perform some JDBC access
|
||||
Hibernate session obtains a connection when it first needs to perform some JDBC access
|
||||
and holds unto that connection until the session is closed.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
|
@ -237,7 +237,7 @@ public class Event {
|
|||
</hibernate-mapping>]]></programlisting>
|
||||
|
||||
<para>
|
||||
The <literal>id</literal> element is the declaration of the identifer property,
|
||||
The <literal>id</literal> element is the declaration of the identifier property,
|
||||
<literal>name="id"</literal> declares the name of the Java property -
|
||||
Hibernate will use the getter and setter methods to access the property.
|
||||
The column attribute tells Hibernate which column of the
|
||||
|
@ -776,7 +776,7 @@ else if (args[0].equals("list")) {
|
|||
<listitem>
|
||||
<para>
|
||||
Now disable hbm2ddl by commenting out the property in your <literal>hibernate.cfg.xml</literal>
|
||||
file. Usually you only leave it turned on in continous unit testing, but another
|
||||
file. Usually you only leave it turned on in continuous unit testing, but another
|
||||
run of hbm2ddl would <emphasis>drop</emphasis> everything you have stored - the
|
||||
<literal>create</literal> configuration setting actually translates into "drop all
|
||||
tables from the schema, then re-create all tables, when the SessionFactory is build".
|
||||
|
@ -1144,7 +1144,7 @@ public void setEmailAddresses(Set emailAddresses) {
|
|||
}]]></programlisting>
|
||||
|
||||
<para>
|
||||
This time we didnt' use a <emphasis>fetch</emphasis> query to initialize the collection.
|
||||
This time we didn't use a <emphasis>fetch</emphasis> query to initialize the collection.
|
||||
Hence, the call to its getter method will trigger an additional select to initialize
|
||||
it, so we can add an element to it. Monitor the SQL log and try to optimize this with
|
||||
an eager fetch.
|
||||
|
@ -1216,7 +1216,7 @@ public void setParticipants(Set participants) {
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Many developers program defensive and create link management methods to
|
||||
Many developers program defensively and create link management methods to
|
||||
correctly set both sides, e.g. in <literal>Person</literal>:
|
||||
</para>
|
||||
|
||||
|
@ -1346,7 +1346,7 @@ public class EventManagerServlet extends HttpServlet {
|
|||
|
||||
<para>
|
||||
Finally, the unit of work ends when processing and rendering is complete. If any
|
||||
problem occured during processing or rendering, an exception will be thrown
|
||||
problem occurred during processing or rendering, an exception will be thrown
|
||||
and the database transaction rolled back. This completes the
|
||||
<literal>session-per-request</literal> pattern. Instead of the transaction
|
||||
demarcation code in every servlet you could also write a servlet filter.
|
||||
|
@ -1456,7 +1456,7 @@ out.close();]]></programlisting>
|
|||
That's it, the servlet is complete. A request to the servlet will be processed
|
||||
in a single <literal>Session</literal> and <literal>Transaction</literal>. As
|
||||
earlier in the standalone application, Hibernate can automatically bind these
|
||||
ojects to the current thread of execution. This gives you the freedom to layer
|
||||
objects to the current thread of execution. This gives you the freedom to layer
|
||||
your code and access the <literal>SessionFactory</literal> in any way you like.
|
||||
Usually you'd use a more sophisticated design and move the data access code
|
||||
into data access objects (the DAO pattern). See the Hibernate Wiki for more
|
||||
|
@ -1510,7 +1510,7 @@ out.close();]]></programlisting>
|
|||
Before you compile and deploy the web application, note that an additional library
|
||||
is required: <literal>jsdk.jar</literal>. This is the Java servlet development kit,
|
||||
if you don't have this library already, get it from the Sun website and copy it to
|
||||
your library directory. However, it will be only used for compliation and excluded
|
||||
your library directory. However, it will be only used for compilation and excluded
|
||||
from the WAR package.
|
||||
</para>
|
||||
|
||||
|
|
Loading…
Reference in New Issue