Author: manaRH Date: 2009-06-01 07:24:41 -0400 (Mon, 01 Jun 2009) New Revision: 11063 Modified: branches/community/Seam_2_1/doc/Seam_Reference_Guide/en-US/ClusteringAndEJBPassivation.xml Log: reviewed and fix some typos Modified: branches/community/Seam_2_1/doc/Seam_Reference_Guide/en-US/ClusteringAndEJBPassivation.xml =================================================================== --- branches/community/Seam_2_1/doc/Seam_Reference_Guide/en-US/ClusteringAndEJBPassivation.xml 2009-05-31 22:22:20 UTC (rev 11062) +++ branches/community/Seam_2_1/doc/Seam_Reference_Guide/en-US/ClusteringAndEJBPassivation.xml 2009-06-01 11:24:41 UTC (rev 11063) @@ -46,7 +46,7 @@ <para> But wait, there's more! Seam also offers an incredibly unique feature for clustered applications. In addition to monitoring JavaBean components, Seam ensures that managed entity instances (i.e. JPA and - Hibernate entities) don't become detatched during replication. Seam keeps a record of the entities that are + Hibernate entities) don't become detached during replication. Seam keeps a record of the entities that are loaded and automatically loads them on the secondary node. You must, however, be using a Seam-managed persistence context to get this feature. More in depth information about this feature is provided in the second half of this chapter. @@ -61,7 +61,7 @@ <title>Programming for clustering</title> <para> Any session- or conversation-scoped mutable JavaBean component that will be used in a clustered - environment must implement the <literal>Mutable</literal> interface from the Seam API. As part of the + environment must implement the <literal>org.jboss.seam.core.Mutable</literal> interface from the Seam API. As part of the contract, the component must maintain a dirty flag that is reported and reset by the <literal>clearDirty()</literal> method. Seam calls this method to determine if it is necessary to replicate the component. This avoids having to use the more cumbersome Servlet API to add and remove the @@ -82,7 +82,7 @@ </para> <note> <para> - Please note that clustering does not work with hot deployable compoennts. But then again, you shouldn't + Please note that clustering does not work with hot deployable components. But then again, you shouldn't be using hot deployable components in a non-development environment anyway. </para> </note> @@ -265,7 +265,7 @@ The MEI serves two distinct scenarios (EJB passivation and HTTP session passivation), although to accomplish the same overall goal. It ensures that throughout the life of a conversation using at least one extended persistence context, the entity instances loaded by the persistence context(s) remain managed (they do not - become detatched prematurally by a passivation event). In short, it ensures the integrity of the extended + become detached prematurally by a passivation event). In short, it ensures the integrity of the extended persistence context (and therefore its guarantees). </para> @@ -333,7 +333,7 @@ <para> Conversations were initially designed with stateful session beans (SFSBs) in mind, primarily because the EJB 3 specification designates SFSBs as hosts of the extended persistence context. Seam introduces a - compliment to the extended persistence context, known as a Seam-managed persistence context, which works + complement to the extended persistence context, known as a Seam-managed persistence context, which works around a number of limitations in the specification (complex propagation rules and lack of manual flushing). Both can be used with a SFSB. </para> @@ -354,7 +354,7 @@ individual SFSB. This process can even be disabled. However, the persistence context is not serialized (is this only true of SMPC?). In fact, what happens depends highly on the Java EE container. The spec is not very clear about this situation. Many vendors just tell you not to let it happen if you need the - guarnatees of the extended persistence context. Seam's approach is more conservative. Seam basically + guarantees of the extended persistence context. Seam's approach is more conservative. Seam basically doesn't trust the SFSB with the persistence context or the entity instances. After each invocation of the SFSB, Seam moves the reference to entity instance held by the SFSB into the current conversation (and therefore into the HTTP session), nullifying those fields on the SFSB. It then restores this