December 2009 - jbosscache-commits

Hudson build became unstable: jboss-cache-1.4.X-jdk1.5 #96

by jboss-qa-internal＠redhat.com

See http://hudson.qa.jboss.com/hudson/job/jboss-cache-1.4.X-jdk1.5/96/changes

14 years, 9 months

1
6
0 / 0

Hudson build became unstable: jboss-cache-core-trunk-jdk1.5 » JBoss Cache - Core Edition #880

by jboss-qa-internal＠redhat.com

See http://hudson.qa.jboss.com/hudson/job/jboss-cache-core-trunk-jdk1.5/org.j...

14 years, 11 months

1
2
0 / 0

Hello, jbosscache-commits!

by Tanya

Good Day... I was wondering if you might like to chat with me? I found your profile online and would like to get to know you better. Please email me back Tanya(a)AceMailFast.com

15 years

1
0
0 / 0

9 new ladies profiles (dating)

by Date-online Service

15 years

1
0
0 / 0

Still single?look at my profile, Olga from Russia

by Russian Brides

15 years

1
0
0 / 0

JBoss Cache SVN: r8322 - enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US.

by jbosscache-commits＠lists.jboss.org

Author: laubai Date: 2009-12-14 18:57:54 -0500 (Mon, 14 Dec 2009) New Revision: 8322 Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Author_Group.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Book_Info.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/CacheLoader_FAQ.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Eviction_FAQ.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/General_FAQ.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/JBoss_Cache_Frequently_Asked_Questions.ent enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Revision_History.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/TreeCache_FAQ.xml Log: Tidied tags in Cache FAQ. Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Author_Group.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Author_Group.xml 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Author_Group.xml 2009-12-14 23:57:54 UTC (rev 8322) @@ -4,7 +4,11 @@ <authorgroup> - <author><firstname>Ben Wang, Bela Ban, Manik Surtani, Scott Marlow, Galder Zamarreño </firstname></author> + <author><firstname>Ben Wang, Bela Ban, Manik Surtani, Scott Marlow, Galder Zamarreño</firstname></author> + <editor> + <firstname>Laura</firstname> + <surname>Bailey</surname> + </editor> </authorgroup> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Book_Info.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Book_Info.xml 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Book_Info.xml 2009-12-14 23:57:54 UTC (rev 8322) @@ -3,13 +3,13 @@ <bookinfo> <title>JBoss Cache Frequently Asked Questions</title> - <subtitle>for Use with JBoss Enterprise Application Platform 5.0</subtitle> + <subtitle>for Use with JBoss Enterprise Web Platform 5.0</subtitle> <edition>2.0</edition> <pubsnumber>1</pubsnumber> - <productname>JBoss Enterprise Application Platform</productname> + <productname>JBoss Enterprise Web Platform</productname> <productnumber>5.0</productnumber> <abstract> - <para>This book is a compilation of frequently asked questions about JBoss Cache</para> + <para>This book is a compilation of frequently asked questions about JBoss Cache.</para> </abstract> <isbn>N/A</isbn> <corpauthor> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/CacheLoader_FAQ.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/CacheLoader_FAQ.xml 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/CacheLoader_FAQ.xml 2009-12-14 23:57:54 UTC (rev 8322) @@ -35,48 +35,32 @@ <itemizedlist> <listitem> <para> - <literal>org.jboss.cache.loader.FileCacheLoader</literal> - : this implementation uses the file - system to store and retrieve data. JBoss Cache nodes are mapped - to directories, subnodes to subdirectories etc. Attributes of - a node are mapped to a data file - inside the - directory. + <literal>org.jboss.cache.loader.FileCacheLoader</literal>: this implementation uses the file system to store and retrieve data. JBoss Cache nodes are mapped + to directories, subnodes to subdirectories, etc. Attributes of a node are mapped to a data file inside the directory. </para> </listitem> <listitem> <para> - <literal>org.jboss.cache.loader.jdbm.JdbmCacheLoader</literal> - : this implementation is based on<ulink url="http://jdbm.sourceforge.net/"> - JDBM</ulink>, - an open source file-based transactional persistence engine. + <literal>org.jboss.cache.loader.jdbm.JdbmCacheLoader</literal>: this implementation is based on <ulink url="http://jdbm.sourceforge.net/">JDBM</ulink>, an open source file-based transactional persistence engine. </para> </listitem> <listitem> <para> - <literal>org.jboss.cache.loader.bdbje.BdbjeCacheLoader</literal> - : this implementation is based on the - Oracle's Berkeley DB Java Edition database, a fast and efficient - transactional database. It uses a single file for the entire - store. Note that if you use the Berkeley DB cache loader with - JBoss Cache and wish to ship your product, you will have to acquire a - <ulink url="http://www.sleepycat.com/jeforjbosscache">commercial license from - Oracle</ulink>. + <literal>org.jboss.cache.loader.bdbje.BdbjeCacheLoader</literal>: this implementation is based on Oracle's Berkeley DB Java Edition database, a fast and efficient transactional database. It uses a single file for the entire store. Note that if you use the Berkeley DB cache loader with JBoss Cache and wish to ship your product, you will have to acquire a <ulink url="http://www.sleepycat.com/jeforjbosscache">commercial license from Oracle</ulink>. </para> </listitem> <listitem> <para> - <literal>org.jboss.cache.loader.JDBCCacheLoader</literal> - : this implementation uses the relational database as the persistent - storage. + <literal>org.jboss.cache.loader.JDBCCacheLoader</literal>: this implementation uses the relational database as the persistent storage. </para> </listitem> <listitem> - <para>And more. See the chapter on cache loaders in the Users' Guide for more details. + <para> + And more. See the chapter on cache loaders in the <citetitle>JBoss Cache User Guide</citetitle> for more details. </para> </listitem> </itemizedlist> @@ -91,37 +75,33 @@ <answer> <para> No, it is not. The FileCacheLoader has some severe limitations which restrict its use in a - production - environment, or if used in such an environment, it should be used with due care and sufficient - understanding of these limitations. - </para> + production environment, or if used in such an environment, it should be used with due care and sufficient understanding of these limitations. + </para> <itemizedlist> - <listitem><para>Due to the way the FileCacheLoader represents a tree structure on disk - (directories and - files) traversal is inefficient for deep trees.</para> + <listitem> + <para> + Due to the way the FileCacheLoader represents a tree structure on disk (directories and files) traversal is inefficient for deep trees. + </para> </listitem> - <listitem><para>Usage on shared filesystems like NFS, Windows shares, etc. should be avoided as - these do - not implement proper file locking and can cause data corruption.</para> + <listitem> + <para> + Usage on shared filesystems like NFS, Windows shares, etc. should be avoided as these do not implement proper file locking and can cause data corruption. + </para> </listitem> - <listitem><para>Usage with an isolation level of NONE can cause corrupt writes as multiple threads - attempt to write to the same file.</para> + <listitem> + <para> + Usage with an isolation level of NONE can cause corrupt writes as multiple threads attempt to write to the same file. + </para> </listitem> <listitem> - <para> - File systems are inherently not transactional, so when attempting to use your - cache in a - transactional context, failures when writing to the file (which happens during the - commit phase) - cannot be recovered. - </para> + <para> + File systems are inherently not transactional, so when attempting to use your cache in a transactional context, failures when writing to the file (which happens during the commit phase) cannot be recovered. + </para> </listitem> </itemizedlist> - <para> - As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly - concurrent, - transactional or stressful environment, and its use is restricted to testing. - </para> + <para> + As a rule of thumb, it is recommended that the FileCacheLoader not be used in a highly concurrent, transactional or stressful environment, and its use is restricted to testing. + </para> </answer> </qandaentry> @@ -131,11 +111,8 @@ </question> <answer> - <para>Yes. Set the - <literal>async</literal> - attribute to true. See the JBoss Cache Users' Guide for a more - detailed discussion. By default though, all cache loader writes are - synchronous and will block. + <para> + Yes. Set the <varname>async</varname> attribute to true. See the JBoss Cache Users' Guide for a more detailed discussion. By default though, all cache loader writes are synchronous and will block. </para> </answer> </qandaentry> @@ -144,13 +121,9 @@ <question> <para>Can I write my own cache loader?</para> </question> - <answer> - <para>Yes. A cache loader is a class implementing - <literal>org.jboss.cache.loader.CacheLoader</literal> - or extending - <literal>org.jboss.cache.loader.AbstractCacheLoader</literal>. It is - configured via the XML file (see JBoss Cache Users' Guide). + <para> + Yes. A cache loader is a class implementing <literal>org.jboss.cache.loader.CacheLoader</literal> or extending <literal>org.jboss.cache.loader.AbstractCacheLoader</literal>. It is configured via the XML file (see <citetitle>JBoss Cache User Guide</citetitle>). </para> </answer> </qandaentry> @@ -159,32 +132,25 @@ <question> <para>Does a cache loader have to use a persistent store?</para> </question> - <answer> - <para>No, a cache loader could for example fetch (and possibly store) - its data from a webdav-capable webserver. Another example is a - caching proxy server, which fetches contents from the web. Note that - an implementation of CacheLoader may not implement the 'store' - functionality in this case, but just the 'load' - functionality. + <para>No. A cache loader could, for example, fetch (and possibly store) its data from a webdav-capable webserver. Another example is a caching proxy server, which fetches contents from the web. Note that an implementation of CacheLoader may not implement the 'store' functionality in this case, but just the 'load' functionality. </para> </answer> </qandaentry> - <qandaentry> +  - <qandaentry> +  <qandaentry> <question> @@ -219,26 +185,22 @@ </question> <answer> - <para>Yes. Within the CacheLoaderConfiguration XML - element (see Users' Guide chapter on cache loaders) you can - describe several cache loaders. The impact is that the cache will - look at all of the cache loaders in the order they've been - configured, until it finds a valid, non-null element of data. When - performing writes, all cache loaders are written to (except if the - ignoreModifications element has been set to true for a specific - cache loader). + <para> + Yes. Within the CacheLoaderConfiguration XML element (see the <citetitle>JBoss Cache User Guide</citetitle> chapter on cache loaders) you can describe several cache loaders. The impact is that the cache will look at all of the cache loaders in the order they've been configured, until it finds a valid, non-null element of data. When performing writes, all cache loaders are written to (except if the ignoreModifications element has been set to true for a specific cache loader). </para> </answer> </qandaentry> <qandaentry> <question> - <para>Can I migrate a JDBCacheLoader or FileCacheLoader based cache store containing data formatted with JBoss Cache 1.x.x to JBoss Cache 2.0 format? + <para> + Can I migrate a JDBCacheLoader or FileCacheLoader based cache store containing data formatted with JBoss Cache 1.x.x to JBoss Cache 2.0 format? </para> </question> <answer> - <para>Yes. See "Transforming Cache Loaders" section within the "Cache Loaders" section located in the JBoss Cache Users' Guide. + <para> + Yes. See the "Transforming Cache Loaders" section within the "Cache Loaders" section located in the <citetitle>JBoss Cache User Guide</citetitle>. </para> </answer> </qandaentry> @@ -252,14 +214,10 @@ <answer> <para> - As of JBoss Cache 2.1.0, the answer is yes. See the Users' Guide for details on how to configure - and - tune - your retries and wait period for reestablishing the TCP connection. + As of JBoss Cache 2.1.0, the answer is yes. See the <citetitle>JBoss Cache User Guide</citetitle> for details on how to configure and tune your retries and wait period for reestablishing the TCP connection. </para> <para> - Prior to that, restarting the TCPCacheServer would also mean - restarting your application that uses the cache. + Prior to that, restarting the TCPCacheServer would also mean restarting your application that uses the cache. </para> </answer> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Eviction_FAQ.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Eviction_FAQ.xml 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Eviction_FAQ.xml 2009-12-14 23:57:54 UTC (rev 8322) @@ -11,99 +11,57 @@ </question> <answer> - <para>Yes. JBoss Cache currently supports multiple eviction policies such as LRU, MRU, and FIFO. - Users can also plug in their own eviction policy algorithms. See the JBoss Cache User Guide for details. + <para> + Yes. JBoss Cache currently supports multiple eviction policies such as LRU, MRU, and FIFO. Users can also plug in their own eviction policy algorithms. See the <citetitle>JBoss Cache User Guide</citetitle> for details. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Does JBoss Cache's eviction policy operates in - replication mode? - </para> + <para>Does JBoss Cache's eviction policy operate in replication mode?</para> </question> <answer> <para>Yes and no.</para> - <para>The eviction policy only operates in local mode. That is, nodes are - only evicted locally. This may cause the cache contents not to be - synchronized temporarily. But when a user tries to obtain the cached - contents of an evicted node and finds out that is null (e.g., - <literal>get</literal> - returns null), it should get it from the - other data source and re-populate the data in the cache. During this - moment, the node content will be propagated and the cache content - will be in sync. + <para> + The eviction policy only operates in local mode. That is, nodes are only evicted locally. This may cause the cache contents not to be synchronized temporarily. But when a user tries to obtain the cached contents of an evicted node and finds out that is null (e.g., <literal>get</literal> returns null), it should get it from the other data source and re-populate the data in the cache. During this moment, the node content will be propagated and the cache content will be in sync. </para> - <para>However, you still can run eviction policies with cache mode - set to either - <literal>REPL_SYNC</literal> - or - <literal>REPL_ASYNC</literal>. Depending on your use case, you can - set multiple cache instances to have their own eviction policy - (which are applied locally) or just have selected instances with - eviction policies activated. + <para>However, you still can run eviction policies with cache mode set to either + <literal>REPL_SYNC</literal> or <literal>REPL_ASYNC</literal>. Depending on your use case, you can set multiple cache instances to have their own eviction policy (which are applied locally) or just have selected instances with eviction policies activated. </para> - <para>Also note that, with cache loader option, a locally evicted - node can also be persisted to the backend store and a user can - retrieve it from the store later on. + <para>Also note that, with cache loader option, a locally evicted node can also be persisted to the backend store and a user can retrieve it from the store later on. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Does JBoss Cache support - <literal>Region</literal>? - </para> + <para>Does JBoss Cache support <literal>Region</literal>?</para> </question> <answer> - <para>Yes. JBoss Cache has the notion of region where a user can - configure the eviction policy parameters (e.g., - <literal>maxNodes</literal> - or - <literal>timeToIdleSeconds</literal>) + <para> + Yes. JBoss Cache has the notion of region where a user can configure the eviction policy parameters (e.g., <literal>maxNodes</literal> or <literal>timeToIdleSeconds</literal>) </para> - <para>A region in JBoss Cache denotes a portion of tree hierarchy, - e.g., a fully qualified name (<literal>org.jboss.cache.Fqn</literal>). For example, a user can define - <literal>/org/jboss</literal> - and - <literal>/org/foocom</literal> - as two separate regions. But note - that you can configure the region programmatically now, i.e., - everything has to be configured through the xml file. + <para> + A region in JBoss Cache denotes a portion of tree hierarchy, e.g., a fully qualified name (<literal>org.jboss.cache.Fqn</literal>). For example, a user can define <literal>/org/jboss</literal> and <literal>/org/foocom</literal> as two separate regions. But note that you can configure the region programmatically now, i.e., everything has to be configured through the XML file. </para> </answer> </qandaentry> <qandaentry> <question> - <para>I have turned on the eviction policy, why do I still get "out - of memory" (OOM) exception? - </para> + <para>I have turned on the eviction policy. Why do I still get an Out of Memory (OOM) exception?</para> </question> <answer> - <para>OOM can happen when the speed of cache access exceeds the - speed of eviction policy handling timer. Eviction policy handler - will wake up every - <literal>wakeUpInterval</literal> - milliseconds (or - <literal>wakeUpIntervalSeconds</literal> - seconds, prior to 3.x) - to process the eviction event queue. So when the queue size is full, it will create a - backlog and cause out-of-memory exceptions to happen unless the eviction timer catches - up. To address this problem, in addition to increase the VM heap - size, you can also reduce the - <literal>wakeUpInterval</literal> - so the timer thread - processes the queue more frequently. + <para> + OOM can happen when the speed of cache access exceeds the speed of eviction policy handling timer. Eviction policy handler will wake up every <literal>wakeUpInterval</literal> milliseconds (or <literal>wakeUpIntervalSeconds</literal> seconds, prior to 3.x) to process the eviction event queue. So when the queue size is full, it will create a backlog and cause out-of-memory exceptions to happen unless the eviction timer catches up. To address this problem, in addition to increase the VM heap size, you can also reduce the <literal>wakeUpInterval</literal> so the timer thread processes the queue more frequently. </para> </answer> </qandaentry> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/General_FAQ.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/General_FAQ.xml 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/General_FAQ.xml 2009-12-14 23:57:54 UTC (rev 8322) @@ -11,36 +11,12 @@ </question> <answer> - <para>JBoss Cache is a replicated and transactional cache. It is - replicated since multiple JBoss Cache instances can be distributed - (either within the same JVM or across several JVMs whether they reside on - the same machine or on different machines on a network) and data is - replicated across the whole group. It is transactional because a - user can configure a - <ulink url="http://java.sun.com/products/jta/">JTA</ulink> - compliant transaction - manager and make any cache - interaction transactional, and caches would participate in ongoing JTA transactions. Note that - the cache can also be run without - any replication; this is the local mode. + <para> + JBoss Cache is a replicated and transactional cache. It is replicated since multiple JBoss Cache instances can be distributed (either within the same JVM or across several JVMs whether they reside on the same machine or on different machines on a network) and data is replicated across the whole group. It is transactional because a user can configure a <ulink url="http://java.sun.com/products/jta/">JTA</ulink> compliant transaction manager and make any cache interaction transactional, and caches would participate in ongoing JTA transactions. Note that the cache can also be run without any replication; this is the local mode. </para> - <para>JBoss Cache comes in two flavours: Core and POJO versions. The core library - (using the - <literal>org.jboss.cache.Cache</literal> - interface) is the underlying library that organises data in a tree-like structure and handles - all locking, - passivation, - eviction and replication characteristics of data in the cache. The POJO library (using the - <literal>org.jboss.cache.pojo.PojoCache</literal> - interface) is built atop the core library and allows introspection - of objects in the cache providing transparent coherence by using JBoss AOP. Note that the POJO - edition - of JBoss Cache - (often referred to as POJO Cache) comes with a separate set of documentation (Users' Guide, FAQ, - etc.) - available on the JBoss Cache - <ulink url="http://www.jboss.org/jbosscache/">documentation website</ulink>. + <para> + JBoss Cache comes in two flavours: Core and POJO versions. The core library (using the <literal>org.jboss.cache.Cache</literal> interface) is the underlying library that organises data in a tree-like structure and handles all locking, passivation, eviction and replication characteristics of data in the cache. The POJO library (using the <literal>org.jboss.cache.pojo.PojoCache</literal> interface) is built atop the core library and allows introspection of objects in the cache providing transparent coherence by using JBoss AOP. Note that the POJO edition of JBoss Cache (often referred to as POJO Cache) comes with a separate set of documentation (<citetitle>POJO Cache User Guide</citetitle>, FAQ, etc.) available on the JBoss Cache <ulink url="http://www.jboss.org/jbosscache/">documentation website</ulink>. </para> <!-- <para> @@ -149,13 +125,13 @@ <qandaentry> <question> - <para>Can I run JBoss Cache outside of the JBoss Enterprise Application Platform? + <para>Can I run JBoss Cache outside of the JBoss Enterprise Web Platform? </para> </question> <answer> <para> - Absolutely! Even though JBoss Cache comes integrated with the JBoss Enterprise Application Platform, + Absolutely! Even though JBoss Cache comes integrated with the JBoss Enterprise Web Platform, it can also be used in any other Java EE server such as BEA WebLogic, IBM Websphere or Tomcat. It can also run in a standalone Java process, completely outside of an application server. See the Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/JBoss_Cache_Frequently_Asked_Questions.ent =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/JBoss_Cache_Frequently_Asked_Questions.ent 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/JBoss_Cache_Frequently_Asked_Questions.ent 2009-12-14 23:57:54 UTC (rev 8322) @@ -1,3 +1,3 @@ <!ENTITY HOLDER "Red Hat, Inc"> -<!ENTITY YEAR "2009"> +<!ENTITY YEAR "2010"> <!ENTITY VERSION ""> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Revision_History.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Revision_History.xml 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/Revision_History.xml 2009-12-14 23:57:54 UTC (rev 8322) @@ -8,7 +8,7 @@ <revhistory> <revision> <revnumber>1.0</revnumber> - <date>Wed Oct 21 2009</date> + <date>Tue Dec 15 2009</date> <author> <firstname>Laura</firstname> <surname>Bailey</surname> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/TreeCache_FAQ.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/TreeCache_FAQ.xml 2009-12-10 05:58:21 UTC (rev 8321) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_FAQ/en-US/TreeCache_FAQ.xml 2009-12-14 23:57:54 UTC (rev 8322) @@ -27,10 +27,9 @@ </question> <answer> - <para>Yes. There are some scenarios where you may want to run - multiple instances of JBoss Cache. For example, you want to run - multiple local cache instances with each instance having its own - configuration (e.g., different cache policy). In this case, you will + <para> + Yes. There are some scenarios where you may want to run multiple instances of JBoss Cache. For example, you want to run + multiple local cache instances with each instance having its own configuration (e.g., different cache policy). In this case, you will need multiple xml configuration files. </para> </answer> @@ -38,16 +37,12 @@ <qandaentry> <question> - <para>Can JBoss Cache run as a second level cache inside - Hibernate? - </para> + <para>Can JBoss Cache run as a second level cache inside Hibernate?</para> </question> <answer> - <para>Yes. Since Hibernate 3.0 release, you can configure it to use - JBoss Cache as a second level cache. For details, - see Hibernate documentation, and also see - <ulink url="http://www.jboss.org/community/docs/DOC-10265">this wiki page</ulink>. + <para> + Yes. Since Hibernate 3.0 release, you can configure it to use JBoss Cache as a second level cache. For details, see Hibernate documentation, and also see <ulink url="http://www.jboss.org/community/docs/DOC-10265">this wiki page</ulink>. </para> <para> JBoss Cache 3.x with MVCC in particular works very well as a Hibernate second level cache. @@ -61,10 +56,8 @@ </question> <answer> - <para>It is not necessary to use POJO Cache for second level - cache inside Hibernate because Hibernate - manages fine-grained fields in Java objects. Using POJO Cache won't - provide any advantage, and will be an unnecessary performance drawback. + <para> + It is not necessary to use POJO Cache for second level cache inside Hibernate because Hibernate manages fine-grained fields in Java objects. Using POJO Cache won't provide any advantage, and will be an unnecessary performance drawback. </para> </answer> </qandaentry> @@ -75,12 +68,8 @@ </question> <answer> - <para>You can configure the JBoss Cache through a configuration xml - file or programmatically using a - <literal>org.jboss.cache.config.Configuration</literal> - object, passed in to the - <literal>org.jboss.cache.CacheFactory</literal> - instance. + <para> + You can configure the JBoss Cache through a configuration XML file or programmatically using a <literal>org.jboss.cache.config.Configuration</literal> object, passed in to the <literal>org.jboss.cache.CacheFactory</literal> instance. </para> </answer> </qandaentry> @@ -93,61 +82,23 @@ <answer> <para> - As of JBoss Cache 3.x, yes. An XSD schema is provided in your jbosscache-core.jar file, and is - also - available online, on<ulink url="http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd"> - http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd</ulink>. - You can configure your IDE, text editor or XML authoring tool to use this schema to validate - your file. + As of JBoss Cache 3.x, yes. An XSD schema is provided in your jbosscache-core.jar file, and is also available online, on <ulink url="http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd">http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd</ulink>. You can configure your IDE, text editor or XML authoring tool to use this schema to validate your file. </para> </answer> </qandaentry> <qandaentry> <question> - <para>What is the difference between the different cache modes? - </para> + <para>What is the difference between the different cache modes?</para> </question> <answer> - <para>JBossCache has five different cache modes, i.e., - <literal>LOCAL</literal> - , - <literal>REPL_SYNC</literal> - , - <literal>REPL_ASYNC</literal> - , - <literal>INVALIDATION_SYNC</literal> - and - <literal>INVALIDATION_ASYNC</literal> - . If you want to run JBoss Cache as a - single instance, then you should set the cache mode to - <literal>LOCAL</literal> - so that it won't attempt to replicate anything. - If you want to have synchronous replication among different - JBoss Cache instances, you set it to - <literal>REPL_SYNC</literal> - . - For asynchronous replication, use - <literal>AYSNC_REPL</literal> - . If you do not wish to replicate cached data but simply inform other caches in a cluster that - data - under - specific addresses are now stale and should be evicted from memory, use - <literal>INVALIDATION_SYNC</literal> - or - <literal>INVALIDTAION_ASYNC</literal> - . Synchronous and asynchronous behavior applies to invalidation as well as replication. + <para> + JBossCache has five different cache modes, i.e., <literal>LOCAL</literal>, <literal>REPL_SYNC</literal>, <literal>REPL_ASYNC</literal>, <literal>INVALIDATION_SYNC</literal> and <literal>INVALIDATION_ASYNC</literal>. If you want to run JBoss Cache as a single instance, then you should set the cache mode to <literal>LOCAL</literal> so that it won't attempt to replicate anything. If you want to have synchronous replication among different JBoss Cache instances, you set it to <literal>REPL_SYNC</literal>. For asynchronous replication, use <literal>AYSNC_REPL</literal>. If you do not wish to replicate cached data but simply inform other caches in a cluster that data under specific addresses are now stale and should be evicted from memory, use <literal>INVALIDATION_SYNC</literal> or <literal>INVALIDTAION_ASYNC</literal>. Synchronous and asynchronous behavior applies to invalidation as well as replication. </para> - <para>Note that - <literal>REPL_ASYNC</literal> - and - <literal>INVALIDATION_ASYNC</literal> - are non-blocking. This - can be useful when you want to have another JBoss Cache serving as a - mirror or backup and you don't want to wait for confirmation that this mirror has received your - messages. + <para> + Note that <literal>REPL_ASYNC</literal> and <literal>INVALIDATION_ASYNC</literal> are non-blocking. This can be useful when you want to have another JBoss Cache serving as a mirror or backup and you don't want to wait for confirmation that this mirror has received your messages. </para> </answer> </qandaentry> @@ -158,27 +109,15 @@ </question> <answer> - <para>JBoss Cache leverages - <ulink url="http://www.jgroups.org">JGroups</ulink> - for network communications. A JGroups configuration section is present in your JBoss Cache - configuration. + <para> + JBoss Cache leverages <ulink url="http://www.jgroups.org">JGroups</ulink> for network communications. A JGroups configuration section is present in your JBoss Cache configuration. </para> <para> - A user - can configure the cluster of JBoss Cache instances by sharing the - same cluster name (<literal>cluster name</literal>). There is also - an option of whether to populate the cache data upon starting a new - instance in the - <literal>ClusterConfig</literal> - attribute. + A user can configure the cluster of JBoss Cache instances by sharing the same cluster name (<literal>cluster name</literal>). There is also an option of whether to populate the cache data upon starting a new instance in the <literal>ClusterConfig</literal> attribute. </para> - <para>Note that once all instances join the same replication group, - every replication change is propagated to all participating members. - There is no mechanism for sub-partitioning where some replication - can be done within only a subset of members, unless you use the Buddy Replication features. See - the - Users' Guide for more details on this. + <para> + Note that once all instances join the same replication group, every replication change is propagated to all participating members. There is no mechanism for sub-partitioning where some replication can be done within only a subset of members, unless you use the Buddy Replication features. See the <citetitle>JBoss Cache User Guide</citetitle> for more details on this. </para> </answer> </qandaentry> @@ -189,12 +128,8 @@ </question> <answer> - <para>Yes, both will continue to run, but depending on your replication mode, all transactions or - operations may not complete. If - <literal>REPL_SYNC</literal> - is used, operations will fail while if - <literal>REPL_ASYNC</literal> - is used they will succeed. Even if they succeed though, caches will be out of sync. + <para> + Yes, both will continue to run, but depending on your replication mode, all transactions or operations may not complete. If <literal>REPL_SYNC</literal> is used, operations will fail while if <literal>REPL_ASYNC</literal> is used they will succeed. Even if they succeed though, caches will be out of sync. </para> </answer> </qandaentry> @@ -202,41 +137,28 @@ <qandaentry> <question> - <para>Can I plug in library X instead of JGroups to handle remote calls and group communications? - </para> + <para>Can I plug in library X instead of JGroups to handle remote calls and group communications?</para> </question> <answer> - <para>At this stage the answer is no. We do have an abstraction layer between the - communication suite and JBoss Cache in the pipelines, and this may appear as a feature at some - stage - in - the future. + <para> + At this stage the answer is no. We do have an abstraction layer between the communication suite and JBoss Cache in the pipelines, and this may appear as a feature at some stage + in the future. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Does the cache need to replicate to every other instance in the cluster? Isn't this slow if - the - cluster is large? - </para> + <para>Does the cache need to replicate to every other instance in the cluster? Isn't this slow if the cluster is large?</para> </question> <answer> - <para>Replication need not occur to every node in the cluster. This feature - - called Buddy Replication - - allows each node to pick one or more 'buddies' in the cluster and only replicate to its buddies. - This - allows a cluster to scale - very easily with no extra impact on memory or network traffic with each node added. + <para> + Replication need not occur to every node in the cluster. This feature - called Buddy Replication - allows each node to pick one or more 'buddies' in the cluster and only replicate to its buddies. This allows a cluster to scale very easily with no extra impact on memory or network traffic with each node added. </para> <para> - See the Users' Guide for more information on Buddy Replication, and how it can be used to - achieve very - high - scalability. + See the Users' Guide for more information on Buddy Replication, and how it can be used to achieve very high scalability. </para> </answer> </qandaentry> @@ -246,55 +168,38 @@ <para>I'm using Buddy Replication. Do I need to have some form of session affinity?</para> </question> <answer> - <para>Session affinity relates to returning to the same cache instance for the same data being used. - While this is strictly not a requirement for Buddy Replication, it is greatly recommended to - minimize - moving state around a cluster. + <para>Session affinity relates to returning to the same cache instance for the same data being used. While this is strictly not a requirement for Buddy Replication, it is greatly recommended to minimize moving state around a cluster. </para> </answer> </qandaentry> <qandaentry> <question> - <para>If I have the need for different configuration properties (e.g., - <literal>CacheMode</literal> - and - <literal>IsolationLevel</literal> - ), do I simply need to create multiple - <literal>org.jboss.cache.Cache</literal> - instances with the appropriate configuration? + <para> + If I have the need for different configuration properties (e.g., <literal>CacheMode</literal> and <literal>IsolationLevel</literal>), do I simply need to create multiple <literal>org.jboss.cache.Cache</literal> instances with the appropriate configuration? </para> </question> <answer> - <para>Yes. All the above mentioned properties are per cache - instance. Therefore you will need separate - <literal>org.jboss.cache.Cache</literal> - instances. + <para> + Yes. All the above mentioned properties are per cache instance. Therefore you will need separate <literal>org.jboss.cache.Cache</literal> instances. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Isn't this expensive from a networking standpoint, i.e., needing to create sockets for each - <literal>org.jboss.cache.Cache</literal> - instance? + <para> + Isn't this expensive from a networking standpoint, i.e., needing to create sockets for each <literal>org.jboss.cache.Cache</literal> instance? </para> </question> <answer> <para> - Yes, it can be. For such cases it is recommended that you configure your cache using the JGroups - Multiplexer, which allows several caches to share - a single JGroups channel. Please see the Users' Guide for details on how to configure the - JGroups - Multiplexer. + Yes, it can be. For such cases it is recommended that you configure your cache using the JGroups Multiplexer, which allows several caches to share a single JGroups channel. Please see the Users' Guide for details on how to configure the JGroups Multiplexer. </para> <para> - A faster and more efficient approach is to use a shared transport in JGroups. Please see - <ulink url="http://www.jgroups.org">the JGroups documentation</ulink> - for more details on how to do this. + A faster and more efficient approach is to use a shared transport in JGroups. Please see <ulink url="http://www.jgroups.org">the JGroups documentation</ulink> for more details on how to do this. </para> </answer> </qandaentry> @@ -302,66 +207,50 @@ <qandaentry> <question> - <para>Does the - <literal>ClusterName</literal> - configuration element have - any relation to the JBoss AS cluster - <literal>PartitionName</literal>? - </para> + <para>Does the <literal>ClusterName</literal> configuration element have any relation to the JBoss AS cluster <literal>PartitionName</literal>?</para> </question> <answer> - <para>Yes. They are both JGroups group names. Besides the notion of - a channel in JGroups, it also can partition the channel into different - group names. + <para> + Yes. They are both JGroups group names. Besides the notion of a channel in JGroups, it also can partition the channel into different group names. </para> </answer> </qandaentry> <qandaentry> <question> - <para>When using multiple JGroups based components - (cluster-service.xml, cache [multiple instances]), what is the - correct/valid way to configure those components to make sure my - multicast addresses don't conflict? + <para> + When using multiple JGroups based components (<filename>cluster-service.xml</filename>, cache [multiple instances]), what is the correct/valid way to configure those components to make sure my multicast addresses don't conflict? </para> </question> <answer> - <para>There are two parameters to consider: multicast address (plus - port) and the group name. At minimum, you will have to run - components using a different group name. But whether to run them on - the same channel depends upon whether the communication performance - is critical for you or not. If it is, then it'd be best to run them - on different channels. + <para> + There are two parameters to consider: multicast address (plus port) and the group name. At minimum, you will have to run components using a different group name. But whether to run them on the same channel depends upon whether the communication performance is critical for you or not. If it is, then it'd be best to run them on different channels. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Does JBoss Cache support cache persistence - storage? - </para> + <para>Does JBoss Cache support cache persistence storage?</para> </question> <answer> - <para>Yes. JBoss Cache has a cache loader - interface that supports cache persistence. See below for more FAQs on cache loaders. + <para> + Yes. JBoss Cache has a cache loader interface that supports cache persistence. See below for more FAQs on cache loaders. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Does JBoss Cache support cache passivation/overflow to a data store? - </para> + <para>Does JBoss Cache support cache passivation/overflow to a data store?</para> </question> <answer> - <para>Yes. JBoss Cache uses the - cache loader to support cache passivation/ overflow. See - documentation on how to configure and use this feature. + <para> + Yes. JBoss Cache uses the cache loader to support cache passivation/ overflow. See documentation on how to configure and use this feature. </para> </answer> </qandaentry> @@ -382,32 +271,23 @@ </question> <answer> - <para>No, although it is also on our to do list. Our internal - implementation does use a procedure similar to 2PC to coordinate a - transactions among different instances, but JBoss Cache is not an XA resource. + <para> + No, although it is also on our to do list. Our internal implementation does use a procedure similar to 2PC to coordinate a transactions among different instances, but JBoss Cache is not an XA resource. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Which transaction managers are supported by - JBoss Cache? - </para> + <para>Which transaction managers are supported by JBoss Cache?</para> </question> <answer> - <para>JBoss Cache supports any TransactionManager that is - <ulink url="http://java.sun.com/products/jta/">JTA</ulink> - compliant such as <ulink url="http://www.jboss.org/jbosstm/">JBoss Transactions</ulink>. + <para> + JBoss Cache supports any TransactionManager that is <ulink url="http://java.sun.com/products/jta/">JTA</ulink> compliant such as <ulink url="http://www.jboss.org/jbosstm/">JBoss Transactions</ulink>. </para> <para> - While JBoss Cache does ships with a - dummy transaction manager - (<literal>org.jboss.cache.transaction.DummyTransactionManager</literal>), we do - <emphasis>not</emphasis> - recommend using this for production. It is not thread safe, and is intended for internal testing - only. + While JBoss Cache does ships with a dummy transaction manager (<literal>org.jboss.cache.transaction.DummyTransactionManager</literal>), we do <emphasis>not</emphasis> recommend using this for production. It is not thread safe, and is intended for internal testing only. </para> </answer> </qandaentry> @@ -418,62 +298,27 @@ </question> <answer> - <para>You either use the default transaction manager that ships with JBoss AS - or you have to implement the - <literal>org.jboss.cache.transaction.TransactionManagerLookup</literal> - interface, and return an - instance of your - <literal>javax.transaction.TransactionManager</literal> - implementation. The - configuration property - <literal>TransactionManagerLookupClass</literal> - defines the class - to be used by the cache to fetch a reference to a - transaction manager. It is trivial to implement this interface to support - other transaction managers. Once this attribute is specified, the - cache will look up the transaction context from this transaction - manager. + <para> + You either use the default transaction manager that ships with JBoss AS or you have to implement the <literal>org.jboss.cache.transaction.TransactionManagerLookup</literal> interface, and return an instance of your <literal>javax.transaction.TransactionManager</literal> implementation. The + configuration property <literal>TransactionManagerLookupClass</literal> defines the class to be used by the cache to fetch a reference to a transaction manager. It is trivial to implement this interface to support other transaction managers. Once this attribute is specified, the cache will look up the transaction context from this transaction manager. </para> <para> - The - <literal>org.jboss.cache.transaction.GenericTransactionManagerLookup</literal> - class that ships - with JBoss Cache is able to detect and bind to most popular transaction managers. See the - <literal>GenericTransactionManagerLookup</literal> - Javadocs for more information. + The <literal>org.jboss.cache.transaction.GenericTransactionManagerLookup</literal> class that ships with JBoss Cache is able to detect and bind to most popular transaction managers. See the <literal>GenericTransactionManagerLookup</literal> Javadocs for more information. </para> </answer> </qandaentry> <qandaentry> <question> - <para>How do I control the cache locking level?</para> + <para>How do I control the Cache locking level?</para> </question> <answer> - <para>JBoss Cache lets you control the cache locking level through - the transaction isolation level. This is configured through the - attribute - <literal>IsolationLevel</literal>. The transaction - isolation levels correspond to database - isolation levels, namely, - <literal>NONE</literal>, - <literal>READ_UNCOMMITTED</literal>, - <literal>READ_COMMITTED</literal>, - <literal>REPEATABLE_READ</literal>, and - <literal>SERIALIZABLE</literal>. Note that these isolation levels are ignored if optimistic locking is used. For details, - please - refer - to the - user manual. + <para> + JBoss Cache lets you control the cache locking level through the transaction isolation level. This is configured through the attribute <literal>IsolationLevel</literal>. The transaction isolation levels correspond to database isolation levels, namely <literal>NONE</literal>, <literal>READ_UNCOMMITTED</literal>, <literal>READ_COMMITTED</literal>, <literal>REPEATABLE_READ</literal>, and <literal>SERIALIZABLE</literal>. Note that these isolation levels are ignored if optimistic locking is used. For details, please refer to the <citetitle>JBoss Cache User Guide</citetitle>. </para> <para> - As of JBoss Cache 3.x, when using the MVCC locking scheme, only - <literal>READ_COMMITTED</literal> - and - <literal>REPEATABLE_READ</literal> - are supported. Any other isolation level provided will either be upgraded - or downgraded accordingly. + As of JBoss Cache 3.x, when using the MVCC locking scheme, only <literal>READ_COMMITTED</literal> and <literal>REPEATABLE_READ</literal> are supported. Any other isolation level provided will either be upgraded or downgraded accordingly. </para> </answer> </qandaentry> @@ -484,22 +329,11 @@ </question> <answer> - <para>In JBoss Cache 2.x, by default pessimistic locking is used to lock data nodes, based on the - isolation level - configured. We also offer optimistic locking to allow for greater concurrency - at - the cost of slight processing overhead and performance. See the documentation for a more - detailed - discussion on concurrency and locking in JBoss Cache. + <para> + In JBoss Cache 2.x, by default pessimistic locking is used to lock data nodes, based on the isolation level configured. We also offer optimistic locking to allow for greater concurrency at the cost of slight processing overhead and performance. See the documentation for a more detailed discussion on concurrency and locking in JBoss Cache. </para> <para> - In JBoss Cache 3.x, optimistic and pessimistic locking are deprecated in favour of MVCC - (multi-version concurrency - control), which is far more efficient than either optimistic or pessimistic locking. For a - detailed discussion on - our MVCC implementation, see - <ulink url="http://jbosscache.blogspot.com/2008/07/mvcc-has-landed.html">this blog entry</ulink> - and <ulink url="http://www.jboss.org/community/docs/DOC-10272">this wiki page</ulink>. + In JBoss Cache 3.x, optimistic and pessimistic locking are deprecated in favour of MVCC (multi-version concurrency control), which is far more efficient than either optimistic or pessimistic locking. For a detailed discussion on our MVCC implementation, see <ulink url="http://jbosscache.blogspot.com/2008/07/mvcc-has-landed.html">this blog entry</ulink> and <ulink url="http://www.jboss.org/community/docs/DOC-10272">this wiki page</ulink>. </para> </answer> </qandaentry> @@ -512,26 +346,20 @@ <answer> <para> - Please see the configuration section of the Users' Guide for details. + Please see the configuration section of the <citetitle>JBoss Cache User Guide</citetitle> for details. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Can I use the cache locking level even without a transaction - context? + <para>Can I use the cache locking level even without a transaction context? </para> </question> <answer> - <para>Yes. JBoss Cache controls the individual node locking behavior - through the isolation level semantics. This means even if you don't - use a transaction, you can specify the lock level via isolation - level. You can think of the node locking behavior outside of a - transaction as if it is under transaction with - <literal>auto_commit</literal> - on. + <para> + Yes. JBoss Cache controls the individual node locking behavior through the isolation level semantics. This means even if you don't use a transaction, you can specify the lock level via isolation level. You can think of the node locking behavior outside of a transaction as if it is under transaction with <literal>auto_commit</literal> on. </para> </answer> </qandaentry> @@ -539,57 +367,40 @@ <qandaentry> <question> <para> - Does JBoss Cache support - <literal>SELECT FOR UPDATE</literal> - semantics? + Does JBoss Cache support <literal>SELECT FOR UPDATE</literal> semantics? </para> </question> <answer> <para> - Yes, but this is is only possible if you are running within a JTA transaction - <emphasis>and</emphasis> - are using either - <literal>MVCC</literal> - or - <literal>PESSIMISTIC</literal> - as your node locking scheme. + Yes, but this is is only possible if you are running within a JTA transaction <emphasis>and</emphasis> are using either <literal>MVCC</literal> or <literal>PESSIMISTIC</literal> as your node locking scheme. </para> <para> - To achieve - <literal>SELECT FOR UPDATE</literal> - semantics, simply do: + To achieve <literal>SELECT FOR UPDATE</literal> semantics, simply do: </para> <programlisting role="JAVA"><![CDATA[ +// start transaction ... - // start transaction ... +cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true); +Node n = cache.get("/a/b/c"); // this acquires a WRITE LOCK on this node + ... + ... - cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true); - Node n = cache.get("/a/b/c"); // this acquires a WRITE LOCK on this node - ... - ... - - // end transaction - +// end transaction ]]></programlisting> </answer> </qandaentry> <qandaentry> <question> - <para>With replication (REPL_SYNC/REPL_ASYNC) or invalidation - (INVALIDATION_SYNC/INVALIDATION_ASYNC), how - often does the cache broadcast messages over the network? + <para> + With replication (<literal>REPL_SYNC</literal>/<literal>REPL_ASYNC</literal>) or invalidation (<literal>INVALIDATION_SYNC</literal>/<literal>INVALIDATION_ASYNC</literal>), how often does the cache broadcast messages over the network? </para> </question> <answer> - <para>If the updates are under transaction, then the broadcasts - happen only when the transaction is about to commit (actually - during the prepare stage internally). That is, it will be a batch - update. However, if the operations are not under transaction - context, then each update will trigger replication. Note that this - has performance implications if network latency is a problem. + <para> + If the updates are under transaction, then the broadcasts happen only when the transaction is about to commit (actually during the prepare stage internally). That is, it will be a batch update. However, if the operations are not under transaction context, then each update will trigger replication. Note that this has performance implications if network latency is a problem. </para> </answer> </qandaentry> @@ -600,8 +411,8 @@ </question> <answer> - <para>If you do a <literal>cache.removeNode("/myroot")</literal>, it will recursively remove - all the entries under "/myroot". + <para> + If you do a <literal>cache.removeNode("/myroot")</literal>, it will recursively remove all the entries under "/myroot". </para> </answer> </qandaentry> @@ -612,11 +423,8 @@ </question> <answer> - <para>Yes, using a JMX console such as the one shipped with JBoss AS or JDK 5's - <literal>jconsole</literal> - utility. See the chapter titled - <emphasis role="bold">Management Information</emphasis> - in the JBoss Cache Users' Guide for more details. + <para> + Yes, using a JMX console such as the one shipped with JBoss AS or JDK 5's <literal>jconsole</literal> utility. See the chapter titled <emphasis role="bold">Management Information</emphasis> in the <citetitle>JBoss Cache User Guide</citetitle> for more details. </para> </answer> </qandaentry> @@ -624,21 +432,13 @@ <qandaentry> <question> <para> - JBoss Cache uses a - "<literal>:</literal>" - character in its object name. This causes problems with - my MBean server. What can I do about it? + JBoss Cache uses a "<literal>:</literal>" character in its object name. This causes problems with my MBean server. What can I do about it? </para> </question> <answer> <para> This is something we have seen with some MBean servers. By default, JBoss Cache uses - <literal>jboss.cache:service=JBossCache</literal> - as a prefix to all objects it binds in JMX. - To work around this, use the - <literal>-Djbosscache.jmx.prefix</literal> - JVM parameter to pass in - an alternate prefix. + <literal>jboss.cache:service=JBossCache</literal> as a prefix to all objects it binds in JMX. To work around this, use the <code>-Djbosscache.jmx.prefix</code> JVM parameter to pass in an alternate prefix. </para> </answer> </qandaentry> @@ -649,7 +449,8 @@ </question> <answer> - <para>Yes, you can. See the section on configuration in the JBoss Cache Users' Guide. + <para> + Yes, you can. See the section on configuration in the <citetitle>JBoss Cache User Guide</citetitle>. </para> </answer> </qandaentry> @@ -661,10 +462,7 @@ <answer> <para> - As of JBoss Cache 2.0.0, the dependency on JBoss Serialization has been dropped since most of - the - benefits of JBoss Serialization are available in updated Java 5 VMs. Since JBoss Cache 2.0.0 is - baselined on Java 5, there was no need to provide these benefits separately. + As of JBoss Cache 2.0.0, the dependency on JBoss Serialization has been dropped since most of the benefits of JBoss Serialization are available in updated Java 5 VMs. Since JBoss Cache 2.0.0 is baselined on Java 5, there was no need to provide these benefits separately. </para> </answer> </qandaentry> @@ -675,162 +473,91 @@ </question> <answer> - <para>Not right now. JBoss Cache does not support partitioning that a - user can configure to have different set of data residing on - different cache instances while still participating as a replication - group. + <para> + Not right now. JBoss Cache does not support partitioning that a user can configure to have different set of data residing on different cache instances while still participating as a replication group. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Does JBoss Cache handle the concept of application classloading - inside, say, a Java EE container? - </para> + <para>Does JBoss Cache handle the concept of application classloading inside, say, a Java EE container?</para> </question> <answer> - <para>Application-specific classloading is used widely inside a Java EE - container. For example, a web application may require a new - classloader to scope a specific version of the user library. - However, by default JBoss Cache is agnostic to the classloader. In - general, this leads to two kinds of problems: + <para> + Application-specific classloading is used widely inside a Java EE container. For example, a web application may require a new classloader to scope a specific version of the user library. However, by default JBoss Cache is agnostic to the classloader. In general, this leads to two kinds of problems: </para> <itemizedlist> <listitem> - <para>Object instance is stored in cache1 and replicated to - cache2. As a result, the instance in cache2 is created by the - system classloader. The replication may fail if the system - classloader on cache2 does not have access to the required - class. Even if replication doesn't fail, a user thread in cache2 - may not be able to access the object if the user thread is - expecting a type defined by the application classloader. + <para> + Object instance is stored in cache1 and replicated to cache2. As a result, the instance in cache2 is created by the system classloader. The replication may fail if the system classloader on cache2 does not have access to the required class. Even if replication doesn't fail, a user thread in cache2 may not be able to access the object if the user thread is expecting a type defined by the application classloader. </para> </listitem> <listitem> - <para>Object instance is created by thread 1 and will be - accessed by thread 2 (with two different classloaders). - JBoss Cache has no notion of the different classloaders involved. - As a result, you will have a - <literal>ClassCastException</literal>. This is a standard - problem in passing an object from one application space to - another; JBoss Cache just adds a level of indirection in passing - the object. + <para>Object instance is created by thread 1 and will be accessed by thread 2 (with two different classloaders). JBoss Cache has no notion of the different classloaders involved. As a result, you will have a <literal>ClassCastException</literal>. This is a standard problem in passing an object from one application space to another; JBoss Cache just adds a level of indirection in passing the object. </para> </listitem> </itemizedlist> - <para>To solve the first kind of issue JBoss Cache uses a - <literal>CacheMarshaller</literal>. Basically, this allows application code to register a classloader - with a portion of the cache tree for use in handling objects - replicated to that portion. See the - <literal>CacheMarshaller</literal> - section of - the Users' Guide for more details. + <para> + To solve the first kind of issue JBoss Cache uses a <literal>CacheMarshaller</literal>. Basically, this allows application code to register a classloader with a portion of the cache tree for use in handling objects replicated to that portion. See the <literal>CacheMarshaller</literal> section of the <citetitle>JBoss Cache User Guide</citetitle> for more details. </para> - <para>To solve the second kind of issue, you can use the the - <literal>UseLazyDeserialization</literal> - configuration - option in JBoss Cache, which wraps your objects in a - <literal>Marshalledvalue</literal> - wrapper. The - <literal>MarshalledValue</literal> - serializes and deserializes your object on demand, ensuring the proper thread local context - class loader is used each time. + <para> + To solve the second kind of issue, you can use the the <literal>UseLazyDeserialization</literal> configuration option in JBoss Cache, which wraps your objects in a <literal>Marshalledvalue</literal> wrapper. The <literal>MarshalledValue</literal> serializes and deserializes your object on demand, ensuring the proper thread local context class loader is used each time. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Does JBoss Cache currently support pre-event and post-event - notification? + <para>Does JBoss Cache currently support pre-event and post-event notification? </para> </question> <answer> - <para>Yes. A boolean is passed in to each notification callback identifying whether the callback is - before - or after the event. See the - <literal>org.jboss.cache.notifications.annotations.CacheListener</literal> - annotation for details. + <para> + Yes. A boolean is passed in to each notification callback identifying whether the callback is before or after the event. See the <literal>org.jboss.cache.notifications.annotations.CacheListener</literal> annotation for details. </para> </answer> </qandaentry> <qandaentry> <question> - <para>How do I implement a custom listener to listen to - cache events? - </para> + <para>How do I implement a custom listener to listen to cache events?</para> </question> <answer> <para> - See the Users' Guide on this subject. + See the <citetitle>JBoss Cache User Guide</citetitle> on this subject. </para> </answer> </qandaentry> <qandaentry> <question> - <para>Can I use - <literal>UseRegionBasedMarshalling</literal> - attribute in JBoss Cache in order to get - around ClassCastExceptions happening when accessing data in the cache that has just been - redeployed? + <para>Can I use the <literal>UseRegionBasedMarshalling</literal> attribute in JBoss Cache in order to get around ClassCastExceptions happening when accessing data in the cache that has just been redeployed? </para> </question> <answer> - <para>Yes, you can. Originally, cache Marshalling was designed as a - workaround for those replicated caches that upon state transfer did not have access to the - classloaders defining the objects in the cache. + <para> + Yes, you can. Originally, cache Marshalling was designed as a workaround for those replicated caches that upon state transfer did not have access to the classloaders defining the objects in the cache. </para> - <para>On each deployment, JBoss creates a new classloader per the top level deployment artifact, for - example an EAR. You also have to bear in mind that a class in an application server is defined - not - only by the class name but also its classloader. So, assuming that the cache is not deployed as - part - of your deployment, you could deploy an application and put instances of classes belonging to - this - deployment inside the cache. If you did a redeployment and try to do a get operation of the data - previously put, this would result on a ClassCastException. This is because even though the class - names - are the same, the class definitions are not. The current classloader is different to the one - when - the classes were originally put. + <para> + On each deployment, JBoss creates a new classloader per the top level deployment artifact, for example an EAR. You also have to bear in mind that a class in an application server is defined not only by the class name but also its classloader. So, assuming that the cache is not deployed as part of your deployment, you could deploy an application and put instances of classes belonging to this deployment inside the cache. If you did a redeployment and try to do a get operation of the data previously put, this would result in a ClassCastException. This is because even though the class names are the same, the class definitions are not. The current classloader is different to the one when the classes were originally put. </para> - <para>By enabling marshalling, you can control the lifecycle of the data in the cache and if on - undeployment, you deactivate the region and unregister the classloader that you'd have - registered on - deployment, you'd evict the data in the cache locally. That means that in the next deployment, - the - data won't be in the cache, therefore avoiding the problem. Obviously, using marshalling to get - around this problem is only recommended when you have some kind of persistence backing where the - data - survives, for example using CacheLoaders, or when JBoss Cache is used as a second level cache in - a - persistence framework. + <para> + By enabling marshalling, you can control the lifecycle of the data in the cache and if on undeployment, you deactivate the region and unregister the classloader that you'd have registered on deployment, you'd evict the data in the cache locally. That means that in the next deployment, the data won't be in the cache, therefore avoiding the problem. Obviously, using marshalling to get around this problem is only recommended when you have some kind of persistence backing where the data survives, for example using CacheLoaders, or when JBoss Cache is used as a second level cache in a persistence framework. </para> - <para>To implement this feature, please follow the instructions indicated in the example located - in the CacheMarshaller section of the Users' Guide. It's worth noting that instead of a - <literal>ServletContextListener</literal>, you could add this code into an - <literal>MBean</literal> - that contained lifecycle methods, such as - <literal>start()</literal> - and - <literal>stop()</literal>. - The key would be for this MBean to depend on the target cache, so that it can operate as long as - the - cache is up and running. + <para> + To implement this feature, please follow the instructions indicated in the example located in the CacheMarshaller section of the Users' Guide. It's worth noting that instead of a <literal>ServletContextListener</literal>, you could add this code into an <literal>MBean</literal> that contained lifecycle methods, such as <literal>start()</literal> and <literal>stop()</literal>. The key would be for this MBean to depend on the target cache, so that it can operate as long as the cache is up and running. </para> </answer> </qandaentry>

15 years

1
0
0 / 0

JBoss Cache SVN: r8321 - enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US.

by jbosscache-commits＠lists.jboss.org

Author: laubai Date: 2009-12-10 00:58:21 -0500 (Thu, 10 Dec 2009) New Revision: 8321 Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml Log: Added third part of changes for JBPAPP-2964. Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml 2009-12-10 05:58:03 UTC (rev 8320) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml 2009-12-10 05:58:21 UTC (rev 8321) @@ -237,9 +237,7 @@ <section id="configuration_reference"> - <title> - Configuration File Quick Reference - </title> + <title>Configuration File Quick Reference</title> <para>A list of definitions of each of the XML elements attributes used above, and their bean counterparts for programmatic configuration. If the description of an attribute states that it is <emphasis>dynamic</emphasis>, that means it can be changed after the cache is created and started. @@ -599,8 +597,8 @@ <entry>none</entry> <entry>Specifies the <literal>TransactionManagerLookupClass</literal> implementation to use to obtain - a transaction manager. If not specified (and a <literal>TransactionManager</literal> is not injected - using <literal>RuntimeConfig.setTransactionManager()</literal>, the cache will not be able to participate + a transaction manager. If not specified (and a <literal>TransactionManager</literal> is not injected + using <literal>RuntimeConfig.setTransactionManager()</literal>), the cache will not be able to participate in any transactions.</entry> </row> <row> @@ -1005,7 +1003,7 @@ <entry>1</entry> <entry> - The size of the threadpool used to dispatch events to cache listeners that have registered as + The size of the thread pool used to dispatch events to cache listeners that have registered as asynchronous listeners. If this number is less than 1, all asynchronous listeners will be treated as synchronous listeners and notified synchronously. </entry> @@ -1018,7 +1016,7 @@ <entry>50000</entry> <entry> - The size of the bounded queue used by the async listener threadpool. Only considered if + The size of the bounded queue used by the async listener thread pool. Only considered if <literal>asyncPoolSize</literal> is greater than 0. Increase this if you see a lot of threads blocking trying to add events to this queue. </entry>

15 years

1
0
0 / 0

JBoss Cache SVN: r8320 - enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US.

by jbosscache-commits＠lists.jboss.org

Author: laubai Date: 2009-12-10 00:58:03 -0500 (Thu, 10 Dec 2009) New Revision: 8320 Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml Log: Added third part of changes for JBPAPP-2964. Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml =================================================================== --- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml 2009-12-10 05:36:24 UTC (rev 8319) +++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/configuration_reference.xml 2009-12-10 05:58:03 UTC (rev 8320) @@ -237,9 +237,7 @@ <section id="configuration_reference"> - <title> - Configuration File Quick Reference - </title> + <title>Configuration File Quick Reference</title> <para>A list of definitions of each of the XML elements attributes used above, and their bean counterparts for programmatic configuration. If the description of an attribute states that it is <emphasis>dynamic</emphasis>, that means it can be changed after the cache is created and started. @@ -600,7 +598,7 @@ <entry>Specifies the <literal>TransactionManagerLookupClass</literal> implementation to use to obtain a transaction manager. If not specified (and a <literal>TransactionManager</literal> is not injected - using <literal>RuntimeConfig.setTransactionManager()</literal>, the cache will not be able to participate + using <literal>RuntimeConfig.setTransactionManager()</literal>), the cache will not be able to participate in any transactions.</entry> </row> <row> @@ -1005,7 +1003,7 @@ <entry>1</entry> <entry> - The size of the threadpool used to dispatch events to cache listeners that have registered as + The size of the thread pool used to dispatch events to cache listeners that have registered as asynchronous listeners. If this number is less than 1, all asynchronous listeners will be treated as synchronous listeners and notified synchronously. </entry> @@ -1018,7 +1016,7 @@ <entry>50000</entry> <entry> - The size of the bounded queue used by the async listener threadpool. Only considered if + The size of the bounded queue used by the async listener thread pool. Only considered if <literal>asyncPoolSize</literal> is greater than 0. Increase this if you see a lot of threads blocking trying to add events to this queue. </entry>

15 years

1
0
0 / 0

JBoss Cache SVN: r8319 - enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US.

by jbosscache-commits＠lists.jboss.org

Author: laubai Date: 2009-12-10 00:36:24 -0500 (Thu, 10 Dec 2009) New Revision: 8319 Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml Log: Added second part of changes for JBPAPP-2964. Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml =================================================================== --- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml 2009-12-10 05:35:51 UTC (rev 8318) +++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/architecture.xml 2009-12-10 05:36:24 UTC (rev 8319) @@ -169,7 +169,7 @@ </para> <para> In addition to being visitable, commands are also replicable. The JBoss Cache marshallers know how to - efficiently marshall commands and invoke them on remote cache instances using an internal RPC mechanism + efficiently marshal commands and invoke them on remote cache instances using an internal RPC mechanism based on JGroups. </para> </section> @@ -184,13 +184,11 @@ which sits at the start of the interceptor chain. </para> <para> - <literal>InvocationContext</literal> - , as its name implies, holds contextual information associated with a single cache + <literal>InvocationContext</literal>, as its name implies, holds contextual information associated with a single cache method invocation. Contextual information includes associated <literal>javax.transaction.Transaction</literal> or - <literal>org.jboss.cache.transaction.GlobalTransaction</literal> - , + <literal>org.jboss.cache.transaction.GlobalTransaction</literal>, method invocation origin ( <literal>InvocationContext.isOriginLocal()</literal> ) as well as @@ -240,13 +238,11 @@ in delegating classes, such as <literal>SingletonStoreCacheLoader</literal> or - <literal>AsyncCacheLoader</literal> - , + <literal>AsyncCacheLoader</literal>, or may add the <literal>CacheLoader</literal> to a chain using the - <literal>ChainingCacheLoader</literal> - . + <literal>ChainingCacheLoader</literal>. </para> </section> Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml =================================================================== --- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml 2009-12-10 05:35:51 UTC (rev 8318) +++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml 2009-12-10 05:36:24 UTC (rev 8319) @@ -141,7 +141,7 @@ a chain. The impact is that the cache will look at all of the cache loaders in the order they've been configured, until it finds a valid, non-null element of data. When performing writes, all cache loaders are - written to (except if the + written to, except if the <literal>ignoreModifications</literal> element has been set to <literal>true</literal> @@ -190,8 +190,7 @@ whereas a database implementation might define the database URL, name and password to establish a database connection. This configuration is passed to the cache loader implementation via - <literal>CacheLoader.setConfig(Properties)</literal> - . Note that + <literal>CacheLoader.setConfig(Properties)</literal>. Note that backspaces may have to be escaped. </para> @@ -214,7 +213,6 @@ else. Anything else is loaded lazily when accessed. Preloading makes sense when one anticipates using elements under a given subtree frequently. - . </para> <para> @@ -243,22 +241,20 @@ <literal>async</literal> element defaults to - <literal>false</literal> - . + <literal>false</literal>. </para> - <para> - <emphasis role="bold">Note on using the - <literal>async</literal> - element: - </emphasis> + <note> + <title>Note on using the <literal>async</literal> element</title> + <para> there is always the possibility of dirty reads since all writes are performed asynchronously, and it is thus impossible to guarantee when (and even if) a write succeeds. This needs to be kept in mind when setting the <literal>async</literal> element to true. - </para> + </para> + </note> <para> <literal>ignoreModifications</literal> @@ -271,10 +267,8 @@ used by all servers in the network. This feature allows you to write to the 'local' file cache loader but not the shared - <literal>JDBCCacheLoader</literal> - . This property defaults to - <literal>false</literal> - , so writes are propagated to all cache loaders + <literal>JDBCCacheLoader</literal>. This property defaults to + <literal>false</literal>, so writes are propagated to all cache loaders configured. </para> @@ -357,10 +351,8 @@ <literal>class</literal> element that specifies the implementation class that provides the singleton store functionality. This class must extend - <literal>org.jboss.cache.loader.AbstractDelegatingCacheLoader</literal> - , and if absent, it defaults to - <literal>org.jboss.cache.loader.SingletonStoreCacheLoader</literal> - . + <literal>org.jboss.cache.loader.AbstractDelegatingCacheLoader</literal>, and if absent, it defaults to + <literal>org.jboss.cache.loader.SingletonStoreCacheLoader</literal>. </para> <para> @@ -395,8 +387,7 @@ <literal>true</literal> if each node's cache loader is configured with a different location. Default value is - <literal>true</literal> - . + <literal>true</literal>. </para> <para> @@ -412,13 +403,10 @@ if exceeded. Default value is 20000. </para> - <para> - <emphasis role="bold">Note on using the - <literal>singletonStore</literal> - element: - </emphasis> - setting - up a cache loader as a singleton and using cache passivation (via + <note> + <title>Note on using the <literal>singletonStore</literal> element</title> + <para> + Setting up a cache loader as a singleton and using cache passivation (via evictions) can lead to undesired effects. If a node is to be passivated as a result of an eviction, while the cluster is in the process of electing a new coordinator, the data will be lost. This is because no @@ -426,7 +414,8 @@ the cluster will store the passivated node. A new coordinator is elected in the cluster when either, the coordinator leaves the cluster, the coordinator crashes or stops responding. - </para> + </para> + </note> </section> </section> @@ -447,7 +436,7 @@ configuration element contains a <literal>location</literal> - property, which maps to a directory to be used as a persistent store. + property, which maps to a directory to be used as a persistent store (e.g., <literal>location=/tmp/myDataStore</literal> ). Used mainly for testing and not recommended for production use. @@ -501,21 +490,16 @@ <listitem> <para> - <literal>BdbjeCacheLoader</literal> - , which is a cache loader implementation based on the Oracle/Sleepycat's - <ulink url="http://www.oracle.com/database/berkeley-db/index.html">BerkeleyDB Java Edition - </ulink> - . + <literal>BdbjeCacheLoader</literal>, which is a cache loader implementation based on the Oracle/Sleepycat's + <ulink url="http://www.oracle.com/database/berkeley-db/index.html">BerkeleyDB Java Edition</ulink>. </para> </listitem> <listitem> <para> - <literal>JdbmCacheLoader</literal> - , which is a cache loader + <literal>JdbmCacheLoader</literal>, which is a cache loader implementation based on the - <ulink url="http://jdbm.sourceforge.net/">JDBM engine</ulink> - , a fast and free alternative to + <ulink url="http://jdbm.sourceforge.net/">JDBM engine</ulink>, a fast and free alternative to BerkeleyDB. </para> </listitem> @@ -524,7 +508,7 @@ <para>Note that the BerkeleyDB implementation is much more efficient than the filesystem-based implementation, and provides transactional guarantees, but requires a commercial license if distributed with an - application (see http://www.oracle.com/database/berkeley-db/index.html for + application (see <ulink url="http://www.oracle.com/database/berkeley-db/index.html">http://www.oracle.com/database/berkeley-db/index.html</ulink> for details). </para> @@ -594,7 +578,10 @@ <para> <literal>Fqn</literal>s are stored as strings. Node content is stored as a BLOB. - <emphasis>WARNING:</emphasis> + </para> + + <warning> + <para> JBoss Cache does not impose any limitations on the types of objects used in <literal>Fqn</literal> @@ -602,8 +589,7 @@ cache loader requires <literal>Fqn</literal> to contain only objects of type - <literal>java.lang.String</literal> - . Another limitation for + <literal>java.lang.String</literal>. Another limitation for <literal>Fqn</literal> is its length. Since @@ -612,7 +598,8 @@ <literal>VARCHAR</literal> which can store text values up to some maximum length determined by the database in use. - </para> + </para> + </warning> <para>See <ulink url="http://www.jboss.org/community/docs/DOC-10864">this wiki page</ulink> @@ -832,7 +819,7 @@ </loaders> ]]></programlisting> - <para>Cconfiguration example for a cache loader using c3p0 JDBC connection pooling:</para> + <para>Configuration example for a cache loader using c3p0 JDBC connection pooling:</para> <programlisting role="XML"><![CDATA[ <loaders passivation="false" shared="false"> @@ -982,7 +969,7 @@ <listitem><para> <literal>cache.s3.secure</literal> - - The default is<literal>false</literal>: + The default is <literal>false</literal>: Traffic is sent unencrypted over the public Internet. Set to <literal>true</literal> @@ -996,7 +983,7 @@ Name of the bucket to store data. For different caches using the same access key, use a different bucket name. Read the S3 documentation on the definition of a bucket. - The default value is<literal>jboss-cache</literal>.</para> + The default value is <literal>jboss-cache</literal>.</para> </listitem> <listitem><para> @@ -1005,13 +992,13 @@ One of<literal>PATH</literal>,<literal>SUBDOMAIN</literal>, or <literal>VANITY</literal>. Read the S3 documentation on the use of calling domains. - The default value is<literal>SUBDOMAIN</literal>.</para> + The default value is <literal>SUBDOMAIN</literal>.</para> </listitem> <listitem><para> <literal>cache.s3.optimize</literal> - - The default is<literal>false</literal>. + The default is <literal>false</literal>. If true, <literal>put(Map)</literal> operations @@ -1342,11 +1329,11 @@ the FileCacheLoader), or a shared database. Because both nodes access the same store, they don't necessarily need state transfer on startup. - <footnote> + <note> <para>Of course they can enable state transfer, if they want to have a warm or hot cache after startup. </para> - </footnote> + </note> Rather, the <literal>FetchInMemoryState</literal> attribute could be set to false, resulting in a 'cold' cache, that @@ -1427,7 +1414,7 @@ cache are (a) replicated across the cluster and (b) persisted using the cache loader. This means that all datastores have exactly the same state. When replicating changes synchronously and in a transaction, - the two phase commit protocol takes care that all modifications are + the two-phase commit protocol takes care that all modifications are replicated and persisted in each datastore, or none is replicated and persisted (atomic updates). </para> Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml =================================================================== --- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml 2009-12-10 05:35:51 UTC (rev 8318) +++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml 2009-12-10 05:36:24 UTC (rev 8319) @@ -161,12 +161,14 @@ <literal>/a</literal> and<literal>/a/b</literal>. </para> - <para> - N.B. when adding attributes to a resident node, e.g. - <literal>cache.put("/a", "k", "v")</literal> - in the above example, it would make sense to mark the nodes - as non-resident again and let them be considered for eviction.. - </para> + <note> + <para> + When adding attributes to a resident node, e.g. + <literal>cache.put("/a", "k", "v")</literal> + in the above example, it would make sense to mark the nodes + as non-resident again and let them be considered for eviction. + </para> + </note> </section> </section> Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml =================================================================== --- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml 2009-12-10 05:35:51 UTC (rev 8318) +++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/replication.xml 2009-12-10 05:36:24 UTC (rev 8319) @@ -75,9 +75,8 @@ asynchronous or synchronous mode, JBoss Cache will use either a single phase or <ulink - url="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">two phase - commit - </ulink> + url="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">two-phase + commit</ulink> protocol, respectively. </para> @@ -179,8 +178,7 @@ which contains the logic used to select buddies in a network. JBoss Cache currently ships with a single implementation, - <literal>NextMemberBuddyLocator</literal> - , + <literal>NextMemberBuddyLocator</literal>, which is used as a default if no implementation is provided. The <literal>NextMemberBuddyLocator</literal> selects the next member in @@ -226,8 +224,7 @@ <title>BuddyPools</title> <para>Also known as - <emphasis>replication groups</emphasis> - , a buddy + <emphasis>replication groups</emphasis>, a buddy pool is an optional construct where each instance in a cluster may be configured with a buddy pool name. Think of this as an 'exclusive club membership' where when selecting buddies, @@ -489,8 +486,7 @@ <literal>InactiveOnStartup</literal> property is - <literal>true</literal> - . This property is used in + <literal>true</literal>. This property is used in conjunction with region-based marshalling. </para> </listitem> @@ -547,10 +543,8 @@ the <literal>InactiveOnStartup</literal> property is set to - <literal>false</literal> - . If it is - <literal>true</literal> - , state + <literal>false</literal>. If it is + <literal>true</literal>, state transfer amongst the buddies only occurs when the application activates the region on the various members of the group. </para> @@ -586,8 +580,7 @@ <para>"In-memory" state transfer is enabled by setting the cache's <literal>FetchInMemoryState</literal> configuration attribute to - <literal>true</literal> - . + <literal>true</literal>. </para> </listitem> @@ -603,8 +596,7 @@ loader's <literal>fetchPersistentState</literal> attribute to - <literal>true</literal> - . If multiple cache loaders are configured + <literal>true</literal>. If multiple cache loaders are configured in a chain, only one can have this property set to true; otherwise you will get an exception at startup. </para> @@ -616,8 +608,7 @@ cache loader has <literal>fetchPersistentState</literal> set to - <literal>true</literal> - . + <literal>true</literal>. </para> </listitem> </orderedlist> Modified: enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml =================================================================== --- enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml 2009-12-10 05:35:51 UTC (rev 8318) +++ enterprise-docs/tags/JBoss_EAP_5_0_0/Cache_User_Guide/en-US/transactions.xml 2009-12-10 05:36:24 UTC (rev 8319) @@ -230,7 +230,7 @@ <literal>TransactionManager</literal>. </para> - <para>When the transaction commits, we initiate either a one- two-phase commit + <para>When the transaction commits, we initiate either a one-phase or two-phase commit protocol. See <xref linkend="replication.tx" /> for details. </para>

15 years

1
0
0 / 0

JBoss Cache SVN: r8318 - enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US.

by jbosscache-commits＠lists.jboss.org

Author: laubai Date: 2009-12-10 00:35:51 -0500 (Thu, 10 Dec 2009) New Revision: 8318 Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/architecture.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/replication.xml enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/transactions.xml Log: Added second part of changes for JBPAPP-2964. Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/architecture.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/architecture.xml 2009-12-10 04:47:53 UTC (rev 8317) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/architecture.xml 2009-12-10 05:35:51 UTC (rev 8318) @@ -169,7 +169,7 @@ </para> <para> In addition to being visitable, commands are also replicable. The JBoss Cache marshallers know how to - efficiently marshall commands and invoke them on remote cache instances using an internal RPC mechanism + efficiently marshal commands and invoke them on remote cache instances using an internal RPC mechanism based on JGroups. </para> </section> @@ -184,13 +184,11 @@ which sits at the start of the interceptor chain. </para> <para> - <literal>InvocationContext</literal> - , as its name implies, holds contextual information associated with a single cache + <literal>InvocationContext</literal>, as its name implies, holds contextual information associated with a single cache method invocation. Contextual information includes associated <literal>javax.transaction.Transaction</literal> or - <literal>org.jboss.cache.transaction.GlobalTransaction</literal> - , + <literal>org.jboss.cache.transaction.GlobalTransaction</literal>, method invocation origin ( <literal>InvocationContext.isOriginLocal()</literal> ) as well as @@ -240,13 +238,11 @@ in delegating classes, such as <literal>SingletonStoreCacheLoader</literal> or - <literal>AsyncCacheLoader</literal> - , + <literal>AsyncCacheLoader</literal>, or may add the <literal>CacheLoader</literal> to a chain using the - <literal>ChainingCacheLoader</literal> - . + <literal>ChainingCacheLoader</literal>. </para> </section> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml 2009-12-10 04:47:53 UTC (rev 8317) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/cache_loaders.xml 2009-12-10 05:35:51 UTC (rev 8318) @@ -141,7 +141,7 @@ a chain. The impact is that the cache will look at all of the cache loaders in the order they've been configured, until it finds a valid, non-null element of data. When performing writes, all cache loaders are - written to (except if the + written to, except if the <literal>ignoreModifications</literal> element has been set to <literal>true</literal> @@ -190,8 +190,7 @@ whereas a database implementation might define the database URL, name and password to establish a database connection. This configuration is passed to the cache loader implementation via - <literal>CacheLoader.setConfig(Properties)</literal> - . Note that + <literal>CacheLoader.setConfig(Properties)</literal>. Note that backspaces may have to be escaped. </para> @@ -243,22 +242,20 @@ <literal>async</literal> element defaults to - <literal>false</literal> - . + <literal>false</literal>. </para> - <para> - <emphasis role="bold">Note on using the - <literal>async</literal> - element: - </emphasis> - there is always the possibility of dirty reads since + <note> + <title>Using the <literal>async</literal> element</title> + </para> + There is always the possibility of dirty reads since all writes are performed asynchronously, and it is thus impossible to guarantee when (and even if) a write succeeds. This needs to be kept in mind when setting the <literal>async</literal> element to true. - </para> + </para> + </note> <para> <literal>ignoreModifications</literal> @@ -271,10 +268,8 @@ used by all servers in the network. This feature allows you to write to the 'local' file cache loader but not the shared - <literal>JDBCCacheLoader</literal> - . This property defaults to - <literal>false</literal> - , so writes are propagated to all cache loaders + <literal>JDBCCacheLoader</literal>. This property defaults to + <literal>false</literal>, so writes are propagated to all cache loaders configured. </para> @@ -284,8 +279,7 @@ (if <literal>ignoreModifications</literal> is - <literal>false</literal> - ) + <literal>false</literal>) when the cache loader starts up. </para> @@ -346,8 +340,7 @@ Default value for <literal>enabled</literal> is - <literal>false</literal> - . + <literal>false</literal>. </para> <para> @@ -357,10 +350,8 @@ <literal>class</literal> element that specifies the implementation class that provides the singleton store functionality. This class must extend - <literal>org.jboss.cache.loader.AbstractDelegatingCacheLoader</literal> - , and if absent, it defaults to - <literal>org.jboss.cache.loader.SingletonStoreCacheLoader</literal> - . + <literal>org.jboss.cache.loader.AbstractDelegatingCacheLoader</literal>, and if absent, it defaults to + <literal>org.jboss.cache.loader.SingletonStoreCacheLoader</literal>. </para> <para> @@ -395,8 +386,7 @@ <literal>true</literal> if each node's cache loader is configured with a different location. Default value is - <literal>true</literal> - . + <literal>true</literal>. </para> <para> @@ -412,13 +402,10 @@ if exceeded. Default value is 20000. </para> - <para> - <emphasis role="bold">Note on using the - <literal>singletonStore</literal> - element: - </emphasis> - setting - up a cache loader as a singleton and using cache passivation (via + <note> + <title>Using the <literal>singletonStore</literal> element</title> + <para> + Setting up a cache loader as a singleton and using cache passivation (via evictions) can lead to undesired effects. If a node is to be passivated as a result of an eviction, while the cluster is in the process of electing a new coordinator, the data will be lost. This is because no @@ -426,7 +413,8 @@ the cluster will store the passivated node. A new coordinator is elected in the cluster when either, the coordinator leaves the cluster, the coordinator crashes or stops responding. - </para> + </para> + </note> </section> </section> @@ -447,7 +435,7 @@ configuration element contains a <literal>location</literal> - property, which maps to a directory to be used as a persistent store. + property, which maps to a directory to be used as a persistent store (e.g., <literal>location=/tmp/myDataStore</literal> ). Used mainly for testing and not recommended for production use. @@ -455,8 +443,7 @@ <itemizedlist> <listitem> <para> - <literal>FileCacheLoader</literal> - , which is a simple filesystem-based implementation. By default, this cache + <literal>FileCacheLoader</literal>, which is a simple filesystem-based implementation. By default, this cache loader checks for any potential character portability issues in the location or tree node names, for example invalid characters, producing warning messages. These checks can be disabled adding @@ -503,19 +490,15 @@ <para> <literal>BdbjeCacheLoader</literal> , which is a cache loader implementation based on the Oracle/Sleepycat's - <ulink url="http://www.oracle.com/database/berkeley-db/index.html">BerkeleyDB Java Edition - </ulink> - . + <ulink url="http://www.oracle.com/database/berkeley-db/index.html">BerkeleyDB Java Edition</ulink>. </para> </listitem> <listitem> <para> - <literal>JdbmCacheLoader</literal> - , which is a cache loader + <literal>JdbmCacheLoader</literal>, which is a cache loader implementation based on the - <ulink url="http://jdbm.sourceforge.net/">JDBM engine</ulink> - , a fast and free alternative to + <ulink url="http://jdbm.sourceforge.net/">JDBM engine</ulink>, a fast and free alternative to BerkeleyDB. </para> </listitem> @@ -524,7 +507,7 @@ <para>Note that the BerkeleyDB implementation is much more efficient than the filesystem-based implementation, and provides transactional guarantees, but requires a commercial license if distributed with an - application (see http://www.oracle.com/database/berkeley-db/index.html for + application (see <ulink url="http://www.oracle.com/database/berkeley-db/index.html">http://www.oracle.com/database/berkeley-db/index.html</ulink> for details). </para> @@ -542,16 +525,14 @@ </listitem> <listitem> <para> - <literal>ClusteredCacheLoader</literal> - , which allows querying + <literal>ClusteredCacheLoader</literal>, which allows querying of other caches in the same cluster for in-memory data via the same clustering protocols used to replicate data. Writes are <emphasis>not</emphasis> 'stored' though, as replication would take care of any updates needed. You need to specify a property called - <literal>timeout</literal> - , a long value telling the cache + <literal>timeout</literal>, a long value telling the cache loader how many milliseconds to wait for responses from the cluster before assuming a null value. For example, <literal>timeout = 3000</literal> @@ -568,8 +549,7 @@ <para>JBossCache is distributed with a JDBC-based cache loader implementation that stores/loads nodes' state into a relational database. The implementing class is - <literal>org.jboss.cache.loader.JDBCCacheLoader</literal> - . + <literal>org.jboss.cache.loader.JDBCCacheLoader</literal>. </para> <para>The current implementation uses just one table. Each row in the table @@ -594,7 +574,10 @@ <para> <literal>Fqn</literal>s are stored as strings. Node content is stored as a BLOB. - <emphasis>WARNING:</emphasis> + </para> + + <warning> + <para> JBoss Cache does not impose any limitations on the types of objects used in <literal>Fqn</literal> @@ -602,8 +585,7 @@ cache loader requires <literal>Fqn</literal> to contain only objects of type - <literal>java.lang.String</literal> - . Another limitation for + <literal>java.lang.String</literal>. Another limitation for <literal>Fqn</literal> is its length. Since @@ -612,7 +594,8 @@ <literal>VARCHAR</literal> which can store text values up to some maximum length determined by the database in use. - </para> + </para> + </warning> <para>See <ulink url="http://www.jboss.org/community/docs/DOC-10864">this wiki page</ulink> @@ -832,7 +815,7 @@ </loaders> ]]></programlisting> - <para>Cconfiguration example for a cache loader using c3p0 JDBC connection pooling:</para> + <para>Configuration example for a cache loader using c3p0 JDBC connection pooling:</para> <programlisting role="XML"><![CDATA[ <loaders passivation="false" shared="false"> @@ -982,7 +965,7 @@ <listitem><para> <literal>cache.s3.secure</literal> - - The default is<literal>false</literal>: + The default is <literal>false</literal>: Traffic is sent unencrypted over the public Internet. Set to <literal>true</literal> @@ -996,22 +979,22 @@ Name of the bucket to store data. For different caches using the same access key, use a different bucket name. Read the S3 documentation on the definition of a bucket. - The default value is<literal>jboss-cache</literal>.</para> + The default value is <literal>jboss-cache</literal>.</para> </listitem> <listitem><para> <literal>cache.s3.callingFormat</literal> - - One of<literal>PATH</literal>,<literal>SUBDOMAIN</literal>, or + One of<literal>PATH</literal>, <literal>SUBDOMAIN</literal>, or <literal>VANITY</literal>. Read the S3 documentation on the use of calling domains. - The default value is<literal>SUBDOMAIN</literal>.</para> + The default value is <literal>SUBDOMAIN</literal>.</para> </listitem> <listitem><para> <literal>cache.s3.optimize</literal> - - The default is<literal>false</literal>. + The default is <literal>false</literal>. If true, <literal>put(Map)</literal> operations @@ -1023,7 +1006,7 @@ <listitem><para> <literal>cache.s3.parentCache</literal> - - The default is<literal>true</literal>. + The default is <literal>true</literal>. Set this value to <literal>false</literal> if you are using multiple caches @@ -1342,11 +1325,11 @@ the FileCacheLoader), or a shared database. Because both nodes access the same store, they don't necessarily need state transfer on startup. - <footnote> + <note> <para>Of course they can enable state transfer, if they want to have a warm or hot cache after startup. </para> - </footnote> + </note> Rather, the <literal>FetchInMemoryState</literal> attribute could be set to false, resulting in a 'cold' cache, that @@ -1427,7 +1410,7 @@ cache are (a) replicated across the cluster and (b) persisted using the cache loader. This means that all datastores have exactly the same state. When replicating changes synchronously and in a transaction, - the two phase commit protocol takes care that all modifications are + the two-phase commit protocol takes care that all modifications are replicated and persisted in each datastore, or none is replicated and persisted (atomic updates). </para> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml 2009-12-10 04:47:53 UTC (rev 8317) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/eviction_policies.xml 2009-12-10 05:35:51 UTC (rev 8318) @@ -161,12 +161,14 @@ <literal>/a</literal> and<literal>/a/b</literal>. </para> - <para> - N.B. when adding attributes to a resident node, e.g. - <literal>cache.put("/a", "k", "v")</literal> - in the above example, it would make sense to mark the nodes - as non-resident again and let them be considered for eviction.. - </para> + <note> + <para> + When adding attributes to a resident node, e.g. + <literal>cache.put("/a", "k", "v")</literal> + in the above example, it would make sense to mark the nodes + as non-resident again and let them be considered for eviction. + </para> + </note> </section> </section> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/replication.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/replication.xml 2009-12-10 04:47:53 UTC (rev 8317) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/replication.xml 2009-12-10 05:35:51 UTC (rev 8318) @@ -75,9 +75,8 @@ asynchronous or synchronous mode, JBoss Cache will use either a single phase or <ulink - url="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">two phase - commit - </ulink> + url="http://en.wikipedia.org/wiki/Two-phase_commit_protocol">two-phase + commit</ulink> protocol, respectively. </para> @@ -179,8 +178,7 @@ which contains the logic used to select buddies in a network. JBoss Cache currently ships with a single implementation, - <literal>NextMemberBuddyLocator</literal> - , + <literal>NextMemberBuddyLocator</literal>, which is used as a default if no implementation is provided. The <literal>NextMemberBuddyLocator</literal> selects the next member in @@ -226,8 +224,7 @@ <title>BuddyPools</title> <para>Also known as - <emphasis>replication groups</emphasis> - , a buddy + <emphasis>replication groups</emphasis>, a buddy pool is an optional construct where each instance in a cluster may be configured with a buddy pool name. Think of this as an 'exclusive club membership' where when selecting buddies, @@ -489,8 +486,7 @@ <literal>InactiveOnStartup</literal> property is - <literal>true</literal> - . This property is used in + <literal>true</literal>. This property is used in conjunction with region-based marshalling. </para> </listitem> @@ -511,8 +507,7 @@ </para> <para>After registration, the application calls - <literal>cache.getRegion(fqn, true).activate()</literal> - , + <literal>cache.getRegion(fqn, true).activate()</literal>, which initiates a partial state transfer of the relevant subtree's state. The request is first made to the oldest cache instance in the cluster. However, if that instance responds with no state, it is then @@ -523,8 +518,7 @@ <para>Typically when region-based marshalling is used, the cache's <literal>InactiveOnStartup</literal> property is set to - <literal>true</literal> - . This suppresses initial state transfer, + <literal>true</literal>. This suppresses initial state transfer, which would fail due to the inability to deserialize the transferred state. </para> @@ -547,10 +541,8 @@ the <literal>InactiveOnStartup</literal> property is set to - <literal>false</literal> - . If it is - <literal>true</literal> - , state + <literal>false</literal>. If it is + <literal>true</literal>, state transfer amongst the buddies only occurs when the application activates the region on the various members of the group. </para> @@ -586,8 +578,7 @@ <para>"In-memory" state transfer is enabled by setting the cache's <literal>FetchInMemoryState</literal> configuration attribute to - <literal>true</literal> - . + <literal>true</literal>. </para> </listitem> @@ -603,8 +594,7 @@ loader's <literal>fetchPersistentState</literal> attribute to - <literal>true</literal> - . If multiple cache loaders are configured + <literal>true</literal>. If multiple cache loaders are configured in a chain, only one can have this property set to true; otherwise you will get an exception at startup. </para> @@ -616,8 +606,7 @@ cache loader has <literal>fetchPersistentState</literal> set to - <literal>true</literal> - . + <literal>true</literal>. </para> </listitem> </orderedlist> Modified: enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/transactions.xml =================================================================== --- enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/transactions.xml 2009-12-10 04:47:53 UTC (rev 8317) +++ enterprise-docs/tags/JBoss_EWP_5_0_0/Cache_User_Guide/en-US/transactions.xml 2009-12-10 05:35:51 UTC (rev 8318) @@ -230,7 +230,7 @@ <literal>TransactionManager</literal>. </para> - <para>When the transaction commits, we initiate either a one- two-phase commit + <para>When the transaction commits, we initiate either a one-phase or two-phase commit protocol. See <xref linkend="replication.tx" /> for details. </para>

15 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-commits December 2009