[hibernate-commits] Hibernate SVN: r14585 - core/trunk/documentation/manual/src/main/docbook/en-US/content.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Mon Apr 28 01:19:53 EDT 2008
Author: d.plentz
Date: 2008-04-28 01:19:53 -0400 (Mon, 28 Apr 2008)
New Revision: 14585
Modified:
core/trunk/documentation/manual/src/main/docbook/en-US/content/architecture.xml
core/trunk/documentation/manual/src/main/docbook/en-US/content/performance.xml
core/trunk/documentation/manual/src/main/docbook/en-US/content/query_sql.xml
core/trunk/documentation/manual/src/main/docbook/en-US/content/transactions.xml
core/trunk/documentation/manual/src/main/docbook/en-US/content/tutorial.xml
Log:
[HHH-2930] typos in documentation: datatabase, is send, etc
Modified: core/trunk/documentation/manual/src/main/docbook/en-US/content/architecture.xml
===================================================================
--- core/trunk/documentation/manual/src/main/docbook/en-US/content/architecture.xml 2008-04-28 04:56:51 UTC (rev 14584)
+++ core/trunk/documentation/manual/src/main/docbook/en-US/content/architecture.xml 2008-04-28 05:19:53 UTC (rev 14585)
@@ -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
Modified: core/trunk/documentation/manual/src/main/docbook/en-US/content/performance.xml
===================================================================
--- core/trunk/documentation/manual/src/main/docbook/en-US/content/performance.xml 2008-04-28 04:56:51 UTC (rev 14584)
+++ core/trunk/documentation/manual/src/main/docbook/en-US/content/performance.xml 2008-04-28 05:19:53 UTC (rev 14585)
@@ -522,7 +522,7 @@
<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 @@
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 @@
</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 @@
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 @@
</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 @@
</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.
Modified: core/trunk/documentation/manual/src/main/docbook/en-US/content/query_sql.xml
===================================================================
--- core/trunk/documentation/manual/src/main/docbook/en-US/content/query_sql.xml 2008-04-28 04:56:51 UTC (rev 14584)
+++ core/trunk/documentation/manual/src/main/docbook/en-US/content/query_sql.xml 2008-04-28 05:19:53 UTC (rev 14585)
@@ -59,7 +59,7 @@
</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 @@
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 @@
</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 @@
</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>
Modified: core/trunk/documentation/manual/src/main/docbook/en-US/content/transactions.xml
===================================================================
--- core/trunk/documentation/manual/src/main/docbook/en-US/content/transactions.xml 2008-04-28 04:56:51 UTC (rev 14584)
+++ core/trunk/documentation/manual/src/main/docbook/en-US/content/transactions.xml 2008-04-28 05:19:53 UTC (rev 14585)
@@ -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 @@
}]]></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 @@
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 @@
<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 @@
<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 @@
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 @@
<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 @@
<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 @@
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 @@
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 @@
<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 @@
<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>
Modified: core/trunk/documentation/manual/src/main/docbook/en-US/content/tutorial.xml
===================================================================
--- core/trunk/documentation/manual/src/main/docbook/en-US/content/tutorial.xml 2008-04-28 04:56:51 UTC (rev 14584)
+++ core/trunk/documentation/manual/src/main/docbook/en-US/content/tutorial.xml 2008-04-28 05:19:53 UTC (rev 14585)
@@ -237,7 +237,7 @@
</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 @@
<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 @@
}]]></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 @@
</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 @@
<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 @@
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 @@
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>
More information about the hibernate-commits
mailing list