📄 ch07s16.html
字号:
executes inside or outside a transaction.</p><p>
Option B: The container caches the bean between transactions.
However, unlike option A the container does not have exclusive
access to the persistent storage. Therefore, the container will
synchronize the memory state (via ejbLoad) at the beginning of
each transaction. Thus business methods executing in a transaction
context don't see much benefit from the container caching the bean,
whereas business methods executing outside a transaction context
(transaction attributes Never, NotSupported or Supports) access
the cached (and invalid) state of the bean.</p><p>
Option C: The container does not cache bean instances and instances
memory state is synchronized on every transaction start (via ejbLoad).
For business methods executing outside a transaction the synchronization
is done too, but as the ejbLoad executes in the same transaction context
as the triggering business method, the state must still be considered
invalid and might already have changed in the persistent storage when
the business method executes.</p><p>
Option D: This is a JBoss specific feature available from version 2.4. It enables a lazy read schema, where
the beans state is cached between transactions as with option A,
but resynchronized from the persistent storage from time to time
(via ejbLoad). The default time between resynchronizations is 30
seconds but you may configure the time (in seconds) with
<optiond-refresh-rate>42</optiond-refresh-rate>.</p><p>
With all four commit options the container must synchronize the
bean instances cached state with the persistent storage (via ejbStore)
at the end of each transaction (just before a commit is done)
to be sure the whole transactions state is consistently persistet.
As of the EJB specification there is no safe way for the container to
decide, if the beans state actually has changed since transaction
start, so ejbStore is called, even when all access to the beans
business methods was read only. Note, however, that JBoss supports
an optional method public boolean isModified() in the beans
implementation. If this method returns false, the call to ejbStore
is skipped at commit time.</p><p>
A final note to executing business methods outside of a transaction
context: when reading the beans state you always must consider
the result as invalid and usable for rough display purposes only,
i.e. to fill in a large table, having benefit from bean caching (with
options A, B and D) and avoiding unneccessary concurrency; even with
commit option A, though you get the actual state initially, another
concurrent client might change the beans state a microsecond after
your read. Never write access a bean outside a transaction context
believing ejbStore will be called for synchronization, it typically
will not (though somtimes it might, when the container passivates
the bean) be called. Read the EJB specification 1.1 sections 9.1.7.1
and 11.6.3 carefully, if you plan to use the transaction attributes
Never, NotSupported or Supports.</p><p>
To safely write a bean depending on it's current state ever (re)read
and write the bean within one and the same transaction context.
</p></li></ul></div></div><div class="section"><a name="adv.config-cache"></a><div class="titlepage"><div><h3 class="title"><a name="adv.config-cache"></a>Advanced cache configuration</h3></div></div><p>JBoss currently provides the possibility to choose the cache configuration for
each container configuration. You may want
to define your own cache settings, and to do so you must specify them in
jboss.xml under the <instance-cache> tag and
subtags. Currently 2 cache algorithms have been implemented: a no passivation
cache algorithm (so that all the bean are
kept in memory, unless the bean is an entity bean and you specified for it
commit option C), and a least recently used (LRU)
cache algorithm (so that bean less frequently used are passivated to save
server resources).
</p><p>Let's see how to configure both caches. The examples below are about entity
beans, but the cache settings applies as well
for stateful session beans.For the no passivation cache, jboss.xml will look
like this:</p><pre class="programlisting">
<jboss>
<enterprise-beans>
<entity>
<ejb-name>Bean A</ejb-name>
<configuration-name>No Passivation Configuration<configuration-name>
</entity>
<enterprise-beans>
...
<container-configurations>
<container-configuration>
<container-name>No Passivation Configuration</container-name>
...
<instance-cache>org.jboss.ejb.plugins.EntitySessionInstanceCache</instance-cache>
<container-cache-conf>
<cache-policy>org.jboss.ejb.plugins.NoPassivationCachePolicy</cache-policy>
</container-cache-conf>
...
</container-configuration>
</container-configurations>
...
</jboss>
</pre><p>No further settings are available for the no passivation cache.
For the LRU cache, jboss.xml will look like this:</p><pre class="programlisting">
<jboss>
<enterprise-beans>
<entity>
<ejb-name>Bean A</ejb-name>
<configuration-name>LRU Configuration<configuration-name>
</entity>
<enterprise-beans>
...
<container-configurations>
<container-configuration>
<container-name>LRU Configuration</container-name>
...
<instance-cache>org.jboss.ejb.plugins.EntitySessionInstanceCache</instance-cache>
<container-cache-conf>
<cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
<cache-policy-conf>
<min-capacity>5</min-capacity>
<max-capacity>200</max-capacity>
<overager-period>300</overager-period>
<max-bean-age>600</max-bean-age>
<resizer-period>400</resizer-period>
<max-cache-miss-period>60</max-cache-miss-period>
<min-cache-miss-period>1</min-cache-miss-period>
<cache-load-factor>0.75</cache-load-factor>
</cache-policy-conf>
</container-cache-conf>
...
</container-configuration>
</container-configurations>
...
</jboss>
</pre><div class="itemizedlist"><ul><li><p><a name="d0e2842"></a><cache-policy-conf> and its subtags are optional, so you
can specify none, few or all of them.
<min-capacity> specifies the minimum capacity of the cache. The
cache can be empty, but will have room for at least
5 beans (in the above case); this value cannot be less than 2; the resizer
(see below) will shrink the cache capacity
down to but not less than this value.
</p></li><li><p><a name="d0e2845"></a><max-capacity> specifies the maximum capacity of the
cache. The cache can be empty, but will have room for at most 200
beans (in the above case); this value cannot be less than the minimum
capacity; the resizer (see below) will enlarge the
cache capacity up to but not more than this value.
</p></li><li><p><a name="d0e2848"></a><overager-period> specifies the period of the overager,
that is a periodic task that runs (in the above case) every 300
seconds. Purpose of this periodic task is to see if in the cache there are
very old beans, and to passivate them.
The age at which a bean is considered too old is also configurable (see
below). While the period of this task is 300 seconds, the first run happens at
a random time between 0 and 300 seconds.
</p></li><li><p><a name="d0e2851"></a><max-bean-age> specifies the max age a bean can have
before being passivated by the overager (in this case 600 seconds).
The tag <resizer-period> specifies the period of the resizer, that
is a periodic task that runs (in the above case) every
400 seconds. Purpose of this periodic task is to shrink / enlarge the cache
capacity upon 3 other parameters (see below).
While the period of this task is 400 seconds, the first run happens at a
random time between 0 and 400 seconds.
</p></li><li><p><a name="d0e2854"></a><max-cache-miss-period>,<min-cache-miss-period>
and <cache-load-factor> control the resizer in this way: the
number of
cache misses is internally recorded. When the resizer runs, it sees what is
the cache miss rate from the last time it ran.
If there is more than (in the above case) one cache miss every 1 second
(min-cache-miss-period) then the resizer tries to
enlarge the cache; if there is less than (in this case) one cache miss every
60 seconds (max-cache-miss-period) then the
resizer tries to shrink the cache. How much is the cache enlarged / shrinked ?
Here is where the load-factor comes in the
picture. When the resizer shrinks, it tries to shrink the cache so that (in
this case) the ratio number of beans / cache
capacity is 0.75; when the resizer enlarges, it tries to enlarge the cache by
a factor 1 / 0.75 == 1.333 (in the above case) plus a correction calculated
from the cache miss rate (so that the more cache miss rate you have, the more
the cache is enlarged, starting from at least 1.333; so if you really have a
lot of cache misses, the resizer may decide to enlarge the cache of a factor
2.0 instead of 1.333 - if there is room for that).
</p></li></ul></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="ch07.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch07.html"><img src="toc.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/toc.gif" border="0"></a><a href="ch07s13.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch07s13.html"><img src="prev.gif" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/prev.gif" border="0"></a><a href="ch07s22.html" tppabs="http://www.huihoo.org/jboss/online_manual/3.0/ch07s22.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>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -