Bugs item #992657, was opened at 2004-07-16 17:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=992657&group_id=22866
Category: JBossCache
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ari Erin Miller (ari7419)
Assigned to: Nobody/Anonymous (nobody)
Summary: optiond-refresh-rate doesn't synch the cache, it destroys it
Initial Comment:
I'm reporting this bug against 3.2.4, on Windows XP or
Solaris.
Here is the description jboss gives of option d in
AdminDevel_323.pdf:
{
D, is a JBoss specific feature which is not described in
the EJB
specification. It is a lazy read scheme
where bean state is cached between transactions as
with option A, but the
state is periodically resynchronized
with that of the persistent store. The default time
between reloads is 30
seconds, but may
configured using the optiond-refresh-rate element.
}
Based on my black box experimentation, this is how
JBoss actually implements option D:
When you start the server, JBoss kicks off a process
that removes all the beans from cache at an interval
specified by the refresh rate. So if you start your
server at 9:20 A.M. with an optiond-refresh-rate of an
hour, any entities you cache at 10:19 A.M. will be
removed from the cache at 10:20 A.M. The next
removal of all entities from cache will occur at 11:20
A.M., and so on.
I would expect JBoss, rather than removing entities from
cache, to synch the data of those entities with the
data store periodically based on the optiond-refresh-
rate. The end goal of caching data is so that users,
when they request information from your application,
receive a speedy response. Because optionD removes
the cached entities, where the entities that are cached
reflect frequently requested data, those entities have to
be reloaded, meaning the users see a slow response. If
the cached entities were instead merely updated with
the latest data periodically and automatically, then user
requests would not be impacted.
Here is our full configuration, if it is relevant.
<container-configuration extends="Standard
CMP 2.x EntityBean">
<container-name>CMP Cache
Config</container-name>
<container-cache-conf>
<cache-
policy>org.jboss.ejb.plugins.LRUEnterpriseContextCacheP
olicy</cache-policy>
<cache-policy-conf>
<min-capacity>50</min-
capacity>
<max-
capacity>1000000</max-capacity>
<overager-
period>1200</overager-period>
<max-bean-age>86400</max-bean-age>
<resizer-
period>1200</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>
<commit-option>D</commit-option>
<optiond-refresh-
rate>3600</optiond-refresh-rate>
</container-configuration>
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=992657&group_id=22866
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
