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>&lt;class-cache&gt;</literal> and + Alternatively (preferably?), you may specify <literal>&lt;class-cache&gt;</literal> and <literal>&lt;collection-cache&gt;</literal> elements in <literal>hibernate.cfg.xml</literal>. </para> @@ -1124,7 +1124,7 @@ Sets have a primary key consisting of <literal>&lt;key&gt;</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>&lt;set&gt;</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>&lt;resultset&gt;</literal> element to either reuse them accross + <literal>&lt;resultset&gt;</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>&lt;class&gt;</literal> mapping. Note that this concepetually only works + in the <literal>&lt;class&gt;</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>