[JBoss Cache] Document updated/added: "JBossCacheHabanero"
by Manik Surtani
User development,
The document "JBossCacheHabanero", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10262#cf
Document:
--------------------------------------------------------------
h2. JBoss Cache 2.0.0 +"Habanero"+ designs
h3. JDK baseline?
There is a http://www.jboss.com/index.html?module=bb&op=viewtopic&t=84037 around whether Habanero should use Java 5 as a baseline, and http://community.jboss.org/docs/DOC-10738 as a means to providing Java 1.4.x compatible builds. See http://community.jboss.org/docs/DOC-10263 for more details.
Habanero will use Java 5 as it's baseline and make full use of Java 5 language and API features, particularly in place of Doug Lea's concurrent.jar, albeit with some caveats listed on the JBossRetroPitfalls page.
h3. JGroups dependency
In addition, Habanero will ship with and depend on JGroups 2.5, which too is baselined on Java 5.
h3. JSR-107 JCache compliant interfaces
While sticking to a JSR is probably a good thing, for several reasons Habanero will not be JSR-107 compliant:
* JSR-107 is incomplete and is still in flux
* JSR-107 defines a flat, map-like cache. JBoss Cache uses a tree-structured cache.
As such, one of the goals of Habanero is to glean good design ideas off JSR-107 (such as cache factories, interfaces and listeners), follow close naming conventions, and perhaps once the JSR is complete, provide an interface to JBoss Cache that is JSR-107 compliant.
See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82121 on this subject.
h3. Preliminary interfaces
Other discussions on the http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82121 and http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82117 have also been ongoing. Here's one on the http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87333.
In it's current state, we have a concept as follows:
http://community.jboss.org/servlet/JiveServlet/download/10262-16-4666/Hab...
* This raises the Node object as a top-level construct in the cache.
* The cache itself is a wrapper around the root node, providing some additional cache-wide operations.
* All operations performed on the node are relative to the node.
* Cache and Node interfaces are minimalist, providing basic cache functionality.
* SPI interfaces are available to both cache and node, that allow access to some internals.
** Intended to be used by plugin authors and people extending JBoss Cache
** Not indended for use by applications directly.
* New construction mechanism and lifecycle management by the CacheFactory
Please see http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc..., published here. Lots of javadoc comments detail the operation of each method.
h3. Using the new interfaces
Simple usage example:
// create a factory
CacheFactory factory = new CacheFactoryImpl();
// create and start the cache
Cache c = factory.createCache("META-INF/replSync-service.xml");
// add a child node, and put some data in it
c.addChild("/a/b/c").put("key", "value");
// retrieve the child node from the cache
Node abc = c.getChild("/a/b/c");
// create a new child
Node n123 = c.addChild("/1/2/3");
// move nodes around
abc.move(n123);
abc.getFqn(); // expecting "/1/2/3/a/b/c"
// add a new child, relative to current node
n123.addChild("/4/5/6").put("key2", "value2");
c.getChild("/1/2/3/4/5/6").get("key2"); // should equal value2
factory.stopCache(c);
h3. Implementing Habanero
For Habanero, these new interfaces and APIs will be implemented as simple wrappers around the existing, proven TreeCache. In a later release, possibly JBoss Cache 2.1.0, the internals of how the cache and tree is organised may change, but the interfaces and API defined here will be adhered to.
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossRetroPitfalls"
by Manik Surtani
User development,
The document "JBossRetroPitfalls", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10739#cf
Document:
--------------------------------------------------------------
This page captures some of the pitfalls encountered when writing Java 5 code and expecting it to work with Java 1.4.x after retroweaving with JBossRetro.
Note that these have been encountered with JBoss Retro 1.0.4.GA - future versions may not have these problems.
* New java.util.Timer constructors which take in Strings are translated to their unnamed equivalents. This means that the name passed to the Timer constructor will not be assigned to the associated
java.util.TimerThread
. See http://jira.jboss.com/jira/browse/JBBUILD-350
* Anonymous implementation of abstract methods in enums causes Weaver to barf - don't use these. See http://jira.jboss.com/jira/browse/JBBUILD-332
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCache200Migration"
by Manik Surtani
User development,
The document "JBossCache200Migration", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10246#cf
Document:
--------------------------------------------------------------
This page is for users of JBoss Cache 1.x.x who wish to move to JBoss Cache 2.x.x, and talks about how things have changed, and how existing code can be migrated to the new APIs.
It is assumed that you have already read the JBoss Cache http://labs.jboss.com/jbosscache/docs/index.html.
*Q:* Where is TreeCache?
*A:* TreeCache, the central class in JBoss Cache 1.x.x, has been removed in favour of API access via a Cache interface. This gives the implementation more flexibility, and adds further safety by restricting the API methods exposed.
*Q:* Can Nodes be directly manipulated now, and will aspects such as locking, replication and cache loading still be applied?
*A:* Yes. JBoss Cache 1.x.x exposed Node objects but did not apply any of the JBoss Cache aspects when directy manipulating a Node. In 2.0.0 we have promoted Node to a top-level construct and it is in fact encouraged to use Nodes directly rather than operations on Cache.
*Q:* How do I create a Cache then?
*A:* Use a CacheFactory. JBoss Cache 2.0.0 ships with a DefaultCacheFactory implementation. See the http://labs.jboss.com/jbosscache/docs/index.html for examples.
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCacheHibernateAlignment"
by Manik Surtani
User development,
The document "JBossCacheHibernateAlignment", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10266#cf
Document:
--------------------------------------------------------------
h3. What is this page about?
This page is about aligning JBossCache and Hibernate better in ideological terms, with a goal to improve the integration of and interoperability between these two products and make JBossCache the default caching provider in Hibernate.
h3. Discussion
Details of discussions about this subject are on http://www.jboss.org/index.html?module=bb&op=viewtopic&t=88929
h3. Issues at Hand
1. Hibernate's caching needs involve caching 4 separate types of objects: entities, collections, queries and update-timestamps (related to queries), each requiring different caching characteristics.
2. When dealing with entities, JBossCache has a concept of a put(), which puts data into the cache. Hibernate, on the other hand, has 2 separate notions of a put() - one is where data is READ from the database and put into the cache, and the other is where data is WRITTEN to the database and put into the cache. The two cases drive separate requirements and behavioural patterns for locking, etc.
3. When dealing with entities, the way Hibernate organises data in the tree structure of JBossCache leads to inefficiencies and contention with concurrent threads.
4. Replicating user types can cause issues when the classloader that loads JBoss Cache does not have visibility to the types being replicated. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=95748 for details.
5. JBoss Cache and Hibernate both make use of the JTA Synchronization interface, with an implicit assumption that the Hibernate synchronization will be called before the JBC one. This is an invalid assumption, as the JTA spec makes no guarantee of ordering between synchronizations. The fact that this usually works is due to an implementation detail of various transaction managers. We have found that with JBossTS it often fails. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97247 for further discussion.
6. JBoss Cache 1.x and 2.x are API incompatible. We need to develop a strategy for dealing in the Hibernate code base with the existence of two incompatible JBC flavors.
7. Using JBossCache as second level cache and optimistic locking, rollbacks can still happen in systems under load as concurrent transactions could be modifying data in the cache. This is a currently pushed back to the Hibernate clients. http://opensource.atlassian.com/projects/hibernate/browse/HHH-2340
h3. Solutions
Based on some of the ideas discussed on the forum threads above, as well as phone and face-to-face discussions between JBossCache and Hibernate folk, we have a few steps that can be taken to overcome the issues at hand.
1. The solution for this is:
* In the short term, for Hibernate to provide a TreeCacheProvider that creates 3 JBossCache instances, one for each cache type. The JBossCache instances should be configured using http://jira.jboss.com/jira/browse/JBCACHE-812 http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc... to significantly reduce the "weight" of multiple JBoss Cache instances.
* In the long term, to define the different caches explicitly within Hibernate.
2. The solution here is to create a putForExternalRead() method in JBossCache, which Hibernate could call when doing a database READ. The characteristics of such a method would be:
* Suspend all ongoing TXs.
* If using pessimistic locking, use weaker locking semantics (READ_UNCOMMITTED? - needs further discussion)
* Quieter logging. Errors and the like that would otherwise raise alarm bells should be suppressed since this is a non-critical call.
* Run this call in a separate thread, so it does not block (? Needs discussion too - should this be the responsibility of the TreeCacheProvider in Hibernate?)
3. Consider the use of hash buckets under the 'type' node so that contention is reduced?
4. The Hibernate Cache implementation(s) for JBC should make use of the JBC region-based marshalling feature.
5. No clear solution at this point.
6. Different providers? We currently have TreeCacheProvider and OptimisticTreeCacheProvider. How about a org.hibernate.cache.jbosscache200.PessimisticCacheProvider and org.hibernate.cache.jbosscache200.OptimisticCacheProvider ??
7. Hibernate should either retry or JBossCache should fail silently on this. As long as the data is stored in the db correctly, failure putting the data in the cache could fail silently. Next time someone requests the entity, it'd be retrieved from db and put in the cache.
h3. Update (2007/07/04)
There are currently a bunch of EJB3 clustered entity test failures in AS trunk due to a bad interaction between Hibernate 3.2.4.SP1 and JBoss Cache 2.0.0. Basically, this is a temporary mismatch between the Hibernate and JBC releases currently integrated in AS trunk. There's work in Hibernate Core's trunk for the 3.3 release that can let us resolve this, but for now the tests are going to fail.
Problem is the integration layer ends up calling the above discussed JBC putForExternalRead() method when it needs to cache something in the "UpdateTimestampsCache". JBC treats a call to this method as a no-op if the cache node in question already exists. This is new behavior in JBC 2.0. It's the necessary and intended behavior when the method is called for caching entities and collections. But when it's called for the UpdateTimestampsCache, it causes problems. The Hibernate 3.3. codebase gives us the flexibility to call a different method for the UpdateTimestampsCache call; to fix the problem we need determine the exact behavior we want for the UpdateTimestampsCache call and make the appropriate call to JBC.
The JBC and Hibernate teams will be meeting the week of July 23rd to sort through the various issues on discussed on this page; the UpdateTimestampsCache issue will be one of the items we'll resolve.
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCache2.xQA"
by Manik Surtani
User development,
The document "JBossCache2.xQA", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10245#cf
Document:
--------------------------------------------------------------
h2. QA Process for JBoss Cache
http://wiki.jboss.org/wiki/Wiki.jsp?page=QAPreReleaseChecklist
1. 2 weeks prior to release the JBoss Cache team should open a JIRA issue in the JBoss QA project detailing what will be released, the date it is expected to be released on, and the CVS tag which will be used for the release. The JIRA will also note the name of any JBoss AS release (or AS branch head) with which the release must be compatible.
2. On release day Cache team will tag their project appropriately and enter a comment on the JIRA issue notifying QA that the project is now ready for the QA process. This Jira issue lives under component
JBossCache
?
3. QA team checks out JBoss Cache from cvs by tag
3.1. +cvs -d:pserver:mailto:anonymous@anoncvs.forge.jboss.com:/cvsroot/jboss co -r TAG JBossCache
+
5. Check if the version information has been updated in /build.xml and src/org/jboss/cache/Version.java
6. Cache also requires the module docbook-support
6.1. svn co https://svn.jboss.org/repos/jbossas/trunk/docbook-support docbook-support
8. QA team then builds the cache project using the target distr
8.1. Build should be performed using *JDK 5.0* version compiler
8.2. cd JBossCache
8.3. ./build.sh dist. This will produce the following packages:
8.3.1. JBossCache-core-xxx. Core Cache.
8.3.2. JBossCache-pojo-xxx. A superset of core plus PojoCache
8.3.3. JBossCache-all-xxx. Everything plus Javadocs.
8.3.4. bdbje-for-JBossCache-xxx. This can't be bundled so it's a separate package.
10. QA team will run the JBossCache testsuite
10.1. Problems were encountered due to the following files /tmp/je.lck, /tmp/00000000.jdb being present
10.2. Attempt to remove these file before running the testsuite
10.3. Delete all /tmp/JBossCache-, /tmp/Tx, /tmp/a. directories created during the previous run of the cache testsuite.
10.4. Expect other existing files in /tmp to break tests
10.5. ./build.sh all-unittests-cc -Djava.awt.headless=true
10.6. ./build.sh reports
10.7. Examine the reports using cruisecontrol as a baseline, look for any nuances
10.8. Rerun with one-test[Pojocache|-pojocache] -Dtest=<test_case> -Djgroups.stack=<udp/tcp>
12. Sanity checking
12.1. QA team will run the distro testsuite (suggesting from -pojo distro)
12.1.1. Under the unzip directory, ./build.sh run.batch and ./build.sh run.pojocache.batch
12.1.2. That's the same test suite as above but tests are precompiled and no udp/tcp option
12.1.3. The sleepycat jar is required for passage of all tests (in the
bdbje-for-JBossCache
)
12.3. Check all documentation is present and looks ok
12.4. Examine the Changelog.txt
12.5. Run through the tutorial page under Tutorial doc
12.5.1. Under both Dos and Linux
12.7. Run and validate output for examples under /examples/PojoCache/ , instructions to run these examples can be found in /examples/PojoCache//readme.txt
12.8. Run the beanshell tests (Following instruction apply to pre cache 2.0 version). For 2.0 version, to run bean shell, simply follow instructions at dist/JBossCache-all-$VERSION/docs/tutorial/en/html_single/index.html. It's much easier)
12.8.1. from the root dir execute runShellDemo
12.8.1.1. once the beanshell gui has started there 4 bsh files which can be executed, pojocacheWithTx, pojocache, oodb, and plain
12.8.1.2. To execute them type: sourceRelative("plain.bsh");
12.8.1.3. See the tutorial under docs/tutorial/en/pdf/TreeCache.pdf & tutorial-pojo (Section 6: Demo) for further instructions.
12.8.1.3.1. Section 6: Plain Cache, to run plain.bsh
12.8.1.3.2. Section 7: CacheLoader Examples, to run oodb.bsh
12.8.1.3.3. Verify JBCACHE-680
12.8.1.5. See the tutorial under docs/tutorial-pojo/en/pdf/TreeCache.pdf (Section 6: Demo) for further instructions on PojoCache.
12.8.1.5.1. Section 7: PojoCache, to run pojocache.bsh
12.8.1.5.2. Section 8: PojoCache with Transaction, to run PojoCacheWithTx.bsh
14. QA will confirm proper integration with JBoss AS
14.1. The JIRA issue in the QA project will identify any AS release(s) (or branch(es), if the release is meant to be integrated into an unreleased AS version) with which the release must be compatible. If no such release is listed, AS integration testing is not required.
14.2. Check out and build the indicated AS release.
14.3. Replace the /build/output/jboss-xxx/server/all/lib/jboss-cache.jar with the jar from the new JBC release.
14.4. Replace the /build/output/jboss-xxx/server/all/lib/pojocache.jar with the jar from the new JBC release. (Note this is new in 2.0 release.)
14.5. Execute the tests-clustering-all-stacks target in the testsuite
14.6. Check for regressions vs. the JBC release previously included with the release.
16. After passing the tests upload the JBossCache-core-2.x.y.zip, JBossCache-pojo-2.x.y.zip, JBossCache-core-JDK140-2.x.y.zip, JBossCache-all-2.x.y, bdbje-for-JBossCache-2.x.y.zip files found in /dist
17. MD5 checksums should be generated as well
17.1. ftp upload.sourceforge.net/incoming
19. Release on sourceforge
19.1. login to sourceforge and go to jboss project
19.2. administer project
19.3. select jboss-cache
19.4. make a new release
19.5. release the project
21. Release the binary to the repository (now contains jboss-cache.jar and pojocache.jar)
21.1. Check both the jboss-cache.jar, pojocache.jar and jboss-cache-jdk50.jar into the repository
21.1.1. https://svn.jboss.org/repos/repository.jboss.org/jboss/cache
21.3. DO NOT modify the build/build-thirdparty file in any JBoss AS branch. Doing this is the responsibility of the AS developers.
21.4. Release the binary to the Maven2 repository
21.4.1. https://svn.jboss.org/repos/repository.jboss.org/maven2/jboss/jboss-cache
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCacheRegions"
by Manik Surtani
User development,
The document "JBossCacheRegions", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10284#cf
Document:
--------------------------------------------------------------
This is about http://jira.jboss.com/jira/browse/JBCACHE-64
h2. Motivation
To be able to configure caches on a per-region basis.
h2. What can be configured per-region?
h4. Currently (2.x) available:
* Eviction policies
* Class loaders
* State transfer
* PojoCache scoping
h4. For JBCACHE-64 (3.0.0)
* Isolation level (see JBossCacheMVCC)
* Transactional behaviour
** REQUIRES_NEW, NONE, etc.
* Replication (SYNC/ASYNC, INVALIDATION, LOCAL)
* Cache loading
h2. Classes
http://community.jboss.org/servlet/JiveServlet/download/10284-5-4686/Regi...
h2. Defining regions
* An Fqn can define a Node which is the root of the region
* Regions within regions allowed
h3. Configuration
* Each region to have a Configuration, which inherits from it's parent region (if region is within a region) or the cache-wide default (copies it)
* Some elements may be dynamic
** If changing on the fly, acquire an exclusive lock on all nodes in the region (and any sub-regions)
** Update interceptors on all nodes in the region accordingly
** Release exclusive locks
*** Any eviction policy updates in a region will reset eviction queues!
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCacheMarshalledValues"
by Manik Surtani
User development,
The document "JBossCacheMarshalledValues", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10273#cf
Document:
--------------------------------------------------------------
h2. Implicit Marshalled Values - Lazy deserialization of cached objects
The purpose of implicit marshalled values in JBoss Cache is to provide lazy unmarshalling of cached objects when they are retrieved from the cache. These cached objects may have originated from persistent storage (such as a cache loader) or a remote cache instance in a cluster, and hence are only available as a stream of bytes. The benefit of lazy deserialization are twofold:
h4. 1. Much better replication performance.
Since synchronous replication implies that a cache operation does not return until state is replicated across a cluster and an acknowledgement is returned, any time saved in deferring deserialization can be a bit plus in terms of performance. In fact, we have noticed that a very significant amount of time spent in most cache operations is in serialization and deserialization of objects for replication and/or persistent storage. Even if the cache is configured to use asynchronous replication, this can still save on CPU cycles on recipient caches. And in all cases, this speeds up cache loading since not all loading calls actually need or use cached data (such as counting the number of attributes in a node).
h4. 2. Much simpler alternative to region-based class loading
Currently the only way to assign a different class loader for different cached objects is to define a region and assign a class loader to the region. This is necessary/useful when different web applications, for example, share a single cache to replicate application data across a cluster. Since marshalled values deserialize lazily, it will only deserialize if an application that explicitly uses it's state requests the data, and it will be deserialized using the context class loader on the caller's thread. Using marshalled values instead will lead to much simpler and far more performant code paths than using regions.
h3. When do we plan to do this?
*JBoss Cache 2.1.0 +Alegrias+* is the target release for implicit marshalled values.
h3. What do I have to do to enable this?
Nothing. Just be aware that your cached objects are deserialized lazily so writing a further layer on top of the cache to do the same thing is wasteful. If you do have such a further layer, it may make sense to remove that layer. Also, be sure to disable region-based marshalling (disabled by default).
h3. Can I disable this?
Yes. A configuration element - UseLazyDeserialization - will be available. This will default to true but can be disabled.
h3. What actually happens under the hood?
An interceptor - MarshalledValueInterceptor - will be inserted into the cache's interceptor stack just after the TxInterceptor.
All cache read and write methods will be intercepted. In the case of writes, all cached objects will be wrapped in a MarshalledValue object (unless they are in the list of excluded types). In the case of reads (as well as return values for some write operations), the values are inspected and if they are MarshalledValues, they will be replaced with the actual cached object - deserializing if necessary - before returning to the caller.
h4. Excluded types
Types excluded from being wrapped in a MarshalledValue would just be a limited set, consisting of java.lang.String and Java primitives (and their Object wrapper counterparts), as well as arrays of these types (but not other collections of these types).
h3. Using custom objects as attribute keys
While using custom objects (which get implicitly wrapped as MarshalledValues) works well as attribute values in a tree node, the usefulness in laz deserialization is limited when used as attribute keys. This is because, for proper functioning, MarshalledValue.hashCode() and equals() methods need to work off the deserialized instance and not the byte stream, and hashCode() is queried every time an object is placed in a Map as a key. Further, if there are hash collisions, then equals() is called as well.
So while using custom objects as attribute values certainly work well, using them as attribute keys +may not+ fully benefit the goodness of lazy deserialization.
h2. Node.releaseObjectReferences(boolean recursive)
This new API method will allow the user to control flushing of all marshalled value object references to their byte buffers - a sort of lazy serializing - which may be useful when the class representations of the objects are due to change.
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossClusteringPatternFarCache"
by Manik Surtani
User development,
The document "JBossClusteringPatternFarCache", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10292#cf
Document:
--------------------------------------------------------------
h2. Session affinity, large cluster, no replication, use of a far cache
h3. IMPORTANT NOTE:
This page discusses the far cache concept in terms of "sessions". The configuration below is not a supported configuration for http session replication in the JBoss Application Server, and will not necessarily work properly if implemented. Readers of this page should think of the concepts on this page in terms of how to manage cached data that is logically "owned" by one server in a cluster, but which needs to be available to other servers in case of a failover. An HttpSession is conceptually that kind of data, but meeting the servlet spec and the full set of expected behaviors of an HttpSession mean that a sophisticated integration layer is required on top of the JBoss Cache. The current integration layer in JBoss AS will not work reliably with the configuration below.
h3. Author
Manik Surtani (mailto:manik@jboss.org)
h3. Use case
You have a large cluster of application servers and the overhead of replicating state is high. Network traffic and memory usage on each node is a problem and scaling is difficult.
h3. Prerequisites
To use this pattern, you must:
* Use a load balancer
* Use sticky sessions
* JBoss Cache 1.3.0 "Wasabi" and above
h3. Description
JBoss Cache 1.3.0 has several features that can be used to help this scenario, specifically TCP or RMI based delegating cache loaders.
Since sessions are sticky, there is often no need for each node in the cluster to have access to all session data. As such, it is safe to switch off replication altogether - set CacheMode to LOCAL. Immediate savings in replication traffic and memory overhead.
But what happens if a node drops out and another node needs to take over the session data? This is where the far cache comes in. Each cache is configured with a TCP (or RMI) delegating cache loader, called a +far cache+. This cache loader points to a dedicated host somewhere which acts as a large in-memory far cache. Using (potentially asynchronous) cache loader semantics, each cache writes back to the far cache as a single backup store of data.
http://community.jboss.org/servlet/JiveServlet/download/10292-10-4701/Far...
As shown above, the far cache is implemented as a single, standalone instance of JBoss Cache with a TCP or RMI listener. This can even be deployed as an MBean in JBoss Cache 1.3.0 (see JBoss Cache documentation for this). The far cache can even be optionally backed by a JDBC cache loader to persist it's in-memory state.
h3. Sample configuration
h4. Configuring JBoss Cache on your cluster
<?xml version="1.0" encoding="UTF-8"?>
<server>
<classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"></classpath>
<mbean code="org.jboss.cache.TreeCache"
name="jboss.cache:service=TreeCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<attribute name="CacheMode">LOCAL</attribute>
<attribute name="UseReplQueue">false</attribute>
<attribute name="LockAcquisitionTimeout">10000</attribute>
<attribute name="UseMarshalling">false</attribute>
<attribute name="CacheLoaderConfiguration">
<config>
<shared>true</shared>
<cacheloader>
<class>org.jboss.cache.loader.tcp.TcpDelegatingCacheLoader</class>
<properties>
host=far-cache.mydomain.com
port=7500
</properties>
<async>true</async>
<fetchPersistentState>false</fetchPersistentState>
<ignoreModifications>false</ignoreModifications>
</cacheloader>
</config>
</attribute>
</mbean>
</server>
h4. Deploying a TCP based far cache as an MBean in JBoss AS on a standalone 'far cache' node
<?xml version="1.0" encoding="UTF-8"?>
<server>
<classpath codebase="./lib" archives="jboss-cache.jar"></classpath>
<mbean code="org.jboss.cache.loader.tcp.TcpCacheServer" name="jboss.cache:service=TcpCacheServer">
<depends optional-attribute-name="Cache"
proxy-type="attribute">jboss.cache:service=TreeCache</depends>
<attribute name="BindAddress">${jboss.bind.address:localhost}</attribute>
<attribute name="Port">7500</attribute>
<attribute name="MBeanServerName"></attribute>
<!--<attribute name="CacheName">jboss.cache:service=TreeCache</attribute>-->
</mbean>
</server>
*Referenced by:*
--------------------------------------------------------------
16 years, 2 months
[JBoss Cache] Document updated/added: "JBossCacheHabaneroJava1.4"
by Manik Surtani
User development,
The document "JBossCacheHabaneroJava1.4", was updated Feb 22, 2010
by Manik Surtani.
To view the document, visit:
http://community.jboss.org/docs/DOC-10263#cf
Document:
--------------------------------------------------------------
h2. Running JBoss Cache 2.x under Java 1.4.x
This page details how to run JBoss Cache +Habanero+ series (2.0.0 series) under Java 1.4. +Habanero+ is baselined on Java 5 and makes heavy use of Java 5 features, both language and API. However, using JBossRetro, we are able to provide retroweaved binaries that does run under Java 1.4.
It is important to note that, at least as of this writing, there is no commercial support for retroweaved binaries offered by Red Hat Inc.
h3. What you will need
h4. Habanero source tree
The source tree of JBoss Cache +Habanero+ from CVS - see JBossCacheDevelopment for details of how to get this.
h4. A compatible version of JGroups.
While +Habanero+ ships with JGroups 2.5, JGroups 2.5 is also baselined on Java 5. This means that the retroweaved binary of JBoss Cache will need to link against a version of JGroups that is both compatible with JBoss Cache as well as Java 1.4. Here, you have 2 options:
* An older version of JGroups.
+Habanero+ does not make any specific use of JGroups 2.5 APIs. This means that +Habanero+ should run just as happily with JGroups >= 2.3. However, it is important to note that some protocols in the JGroups stack may not be present in older JGroups versions. Visit http://www.jgroups.org for more details.
* Retroweave JGroups as well.
This is a fairly simple process. You will need to download the JGroups 2.5 source distribution, and retroweave the resulting binaries yourself. Please refer to the examples and (brief) documentation on the JBossRetro page.
Whichever route you choose, make sure you replace the jgroups.jar file in the lib directory of the JBoss Cache source tree with the version of JGroups you wish to use.
h3. Retroweaving JBoss Cache
This is a fairly straightforward process as well, especially since the build file that is in the JBoss Cache source tree contains an ANT target to do this for you. Note that this target *must* be run with *Java 5*!
./build.sh clean jar-retro
This will create a jar file called jbosscache-JDK140.jar in the dist/lib directory.
h3. Test your build
Ensuring that your *JAVA_HOME* now points to a Java 1.4.x JVM, run:
./build.sh all-unittests-retro-cc reports
HTML-ised reports will be in output/reports/html/
h3. Using the retroweaved binary
Just like the standard distribution of JBoss Cache, the retroweaved version has runtime dependencies on the jars in the lib directory. In addition though, it also has runtime dependencies on the jars in lib/retro so make sure these are made available to your application.
h2. What about PojoCache?
Note that PojoCache does not get retroweaved. There is no plan at this stage to provide a retroweaved binary for PojoCache.
--------------------------------------------------------------
16 years, 2 months
