ch12s31.html

详细介绍了jboss3.0的配置等

         can be edited in a GUI-tool). The interfaces are:</p><p>
					<tt>InstanceCache</tt>,<tt>InstancePool</tt>,<tt>Interceptor</tt>,<tt>EntityPersistenceManager</tt>,<tt>StatefulSessionPersistenceManager</tt>
				</p><p>
					<tt>InstancePool</tt> and<tt>Interceptors</tt> are used in all three different types of
         containers. <tt>InstanceCache</tt> is only used for
entity beans and stateful
         session beans. <tt>EntityPersistenceManager</tt> is
only used for entity beans.
         <tt>StatefulSessionPersistenceManager</tt> is only used
for stateful session
         beans.</p><p>These interfaces are described in detail below. All plugins have
         a callback to the container through which they can access all other
         plugins or configuration information. The container's main
responsibility
         is therefore to manage the plugins, and to see to it that the plugins
have all
         the information they need in order to implement some
functionality.</p><div class="section"><a name="d0e8451"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8451"></a>Interceptor</h5></div></div><div class="section"><a name="d0e8454"></a><div class="titlepage"><div><h6 class="title"><a name="d0e8454"></a>Creation and ordering</h6></div></div><p>All interceptors are created and added to the interceptor
linked-list by
        the container factory. The last interceptor is not added by the
container
        factory but rather by the container itself.</p><p>The order of the interceptor in the chain is not accidental. The
idea
        behind ordering is that intereceptors that are not tied to a particular
        EnterpriseContext instance are positioned before interceptors that
        interact with caches and pools.</p></div></div><div class="section"><a name="d0e8461"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8461"></a>Structure, complexity, cardinality</h5></div></div><p>Implementors of the <tt>Interceptor</tt> interface 
form
        a linked-list like
        structure through which the <tt>MethodInvocation</tt> 
object
is passed. The first
        interceptor in the chain is invoked when<tt>ContainerInvoker</tt> hands off
        <tt>MethodInvocation</tt> to the container.  The last
interceptor invokes the business
        method on the bean. There are usually between 3 and 6 interceptors in
        a chain depending on the bean type and container configuration.
Interceptor
        semantic complexity ranges from simple to complex ones, but under the
        cover they all present the same simple interface. An example of a
        simple interceptor would be <tt>LoggingInterceptor</tt>,
while a complex example is
        <tt>EntitySynchronizationInterceptor</tt>.</p></div><div class="section"><a name="d0e8484"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8484"></a>Advantages</h5></div></div><p>One of the main advantages of <tt>Interceptor</tt>pattern is flexibility
        in the arrangement of interceptors, as well as a clear semantic
distinction
        between different interceptors. For example, logic for transaction and
        security is in <tt>TXInterceptor</tt> and<tt>SecurityInterceptor</tt> correspondingly.</p><p>If any of the interceptors fail, we don't have to continue the call
further
        through, which is very useful if the interceptor that failed is before
complex
        structures like caches.</p></div></div><div class="section"><a name="d0e8500"></a><div class="titlepage"><div><h4 class="title"><a name="d0e8500"></a>Instance Pool</h4></div></div><div class="section"><a name="d0e8503"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8503"></a>Recycling pool for bean instances</h5></div></div><p>
						<tt>InstancePool</tt> is used to manage the EJB-bean
instances that are
         not associated with any identity. In fact, to be exact,
         <tt>EnterpriseContext</tt> objects that wrap
non-associated bean instances
         are pooled in this data structure.</p></div><div class="section"><a name="d0e8514"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8514"></a>Pool types and cardinality</h5></div></div><p>Depending on the underlying bean type hosted in a container, there
         are three different instance pool types.  However, it is important
         to notice that each container has only one pool of either type.</p></div><div class="section"><a name="d0e8519"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8519"></a>Size and roles</h5></div></div><p>Depending on the configuration, a container may choose to have a
certain
         size of the pool containing recycled instances, or it may choose to
         instantiate and initialize an instance on demand.</p><p>The pool is used by the <tt>InstanceCache</tt> to
acquire free instances
         for activation, and it is used by Interceptors to acquire instances
to be
         used for Home interface methods (create and finder calls).</p></div></div><div class="section"><a name="d0e8529"></a><div class="titlepage"><div><h4 class="title"><a name="d0e8529"></a>Instance Cache</h4></div></div><div class="section"><a name="d0e8532"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8532"></a>Container's cache structure</h5></div></div><p>
						<tt>InstanceCache</tt> handles all EJB-instances that are
in a active
        state, i.e. bean instances that have an identity attached to
them.</p></div><div class="section"><a name="d0e8540"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8540"></a>Entity and stateful session bean cache</h5></div></div><p>Only entity and stateful session beans are cached. The cache key
        of an entity bean is the primary key.  It is the session id for 
stateful
        session beans.</p></div><div class="section"><a name="d0e8545"></a><div class="titlepage"><div><h5 class="title"><a name="d0e8545"></a>Roles</h5></div></div><p>
						<tt>InstanceCache</tt> handles the list of active
instances, and is also
        responsible for activating and passivating these instances. If
        an instance with a given identity is requested, and it is not
        currently active, the <tt>InstanceCache</tt> must use
the <tt>InstancePool</tt>        to acquire a free instance, and the persistence manager to
        activate the instance. Similarly, if it decides to passivate
        a certain active instance, it must call the persistence manager
        to passivate it and release the instance to the<tt>InstancePool</tt>.</p></div></div><div class="section"><a name="d0e8562"></a><div class="titlepage"><div><h4 class="title"><a name="d0e8562"></a>EntityPersistenceManager</h4></div></div><p>The <tt>EntityPersistenceManager</tt> is responsible
for the persistence
         of EntityBeans. This includes:</p><p>- Creating EntityBeans in a storage
          - Loading the state of a given primary key into an EJB-instance
          - Storing the state of a given EJB-instance
          - Removing the state from storage
          - Activating an EJB-instance
          - Passivating an EJB-instance</p><p>As per EJB 1.1 specification, JBoss supports two entity bean
         persistance semantics: CMP (Container Managed Persistence) and
         BMP (Bean Managed Persistence).</p><p>The CMP plugin, <tt>CMPPersistanceManager</tt> uses
the default implementor of
         <tt>EntityPersistanceManager</tt>,<tt>JAWSPersistanceManager</tt> (JAWS-Just Another Web Store).
         JAWS performs performs basic O/R functionality against a
JDBC-store.</p><p>The BMP implementor of the <tt>EntityPersistenceManager</tt>interface is
         <tt>BMPPersistanceManager</tt>. BMP persistance manager
is fairly simple
         since all persistence logic is in the entity bean itself. The only
duty of the
         persistence manager is to perform container callbacks.</p></div><div class="section"><a name="d0e8593"></a><div class="titlepage"><div><h4 class="title"><a name="d0e8593"></a>StatefulSessionPersistenceManager</h4></div></div><p>The <tt>StatefulSessionPersistenceManager</tt> is
responsible for
        the persistence of Stateful SessionBeans. This includes:</p><p>- Creating stateful sessions in a storage
        - Activating stateful sessions from a storage
        - Passivating stateful sessions to a storage
        - Removing stateful sessions from a storage</p><p>The default implementation of the<tt>StatefulSessionPersistenceManager</tt>        is <tt>StatefulSessionFilePersistenceManager</tt>. As
its name implies,
        <tt>StatefulSessionFilePersistenceManager</tt> utilizes
the underlying file system
        to persist stateful SessionBeans. More specifically, persistence
manager
        serializes beans in flat file under bean name + bean Id .ser files.
        Having a .ser file per bean instance, the Persistance Manager is able 
to
restore a
        bean's state for activation and respectively store its state during
        passivation.</p></div></div></div><table border="0" cellpadding="0" cellspacing="0" height="65"><tr height="65"><td rowspan="2"><img src="gbar.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/gbar.gif" width="432" height="79"></td><td rowspan="2" background="gbar.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/gbar.gif" width="100%" align="right" valign="top"><a href="index.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/index.html"><img src="doc.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/doc.gif" border="0"></a><a href="ch12.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch12.html"><img src="toc.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/toc.gif" border="0"></a><a href="ch12s21.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch12s21.html"><img src="prev.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/prev.gif" border="0"></a><a href="ch12s63.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch12s63.html"><img src="next.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/next.gif" border="0"></a></td></tr><tr></tr></table></body></html>