a) Associated with a Hibernate Session (transaction scoped) and this cache is used by Hibernate transparently. Hibernate requires a key to load object from the session cache. Hence its better to call a load() or get(), when the key(EntityKey) is known, rather than using a HQL query.
b) All queries (state of an entity, updates) in the cache gets flushed / committed to the database only when  Transaction context ends (i.e.) getTransaction().commit is called.
c) Always used and cannot be turned off.

2)    Second Level Cache (Application Layer)

a) Associated with a Hibernate’s SessionFactory (process scoped). Enabled by default in Hibernate 3 and uses EHCache as default cache provider.
b) The cache entries are dehydrated states of entity objects. A dehydrated state of entity refers to a key­-value  pair where key is the entity id (of the dehydrated entity) and the set of (deep copy) of attribute­values  (dehydrated entity fields) refer to the value.  Hibernate does not cache associations in a dehydrated object by default. One has to manually configured which association in a dehydratable entity to be cached.

Syntax : { id ­> { atribute1, attribute2, attribute3,{attribute41, attribute42},… } }

3)   Query cache (org.hibernate.cache.QueryCache)

a) Defines 2 cache regions : org.hibernate.cache.StandardQueryCache (stores query with parameters as cache key) and org.hibernate.cache.UpdateTimestampsCache (keeps stale query results of last results fetch). Both the cache regions are evicted when the entity related to the cacheable query is updated.

Syntax : { query,{parameters}} —> {id of cached entity}

b) A specific query results are cached, by specifying setCacheable(true) on Session’s Query handle.

1) http://codesearch.google.com – Code hosted on Google Code

2) http://grepcode.com – Maven repository based code search.

3) http://koders.com – Multi programming lingual search.

4) http://www.krugle.org/kse/ – Another language based search

5) http://www.ucodit.com – Neat organization of categories of code retreived.

6) http://www.codase.com/ – Another language based search offering category specific retreival.

1) Synchronize(copy) the lib/*.jar from all to the custom realm (eg. default)
2) Copy the cluster-service.xml  from ‘all’ to your custom realm and retain the mbean with code org.jboss.ha.framework.server.ClusterPartition, removing the other beans, as they are need for advanced configuration.Be-default, the discovery of the other nodes in the partition is identified by UDP configuration specified by PartitionConfig tag.
3) Copy the farm-service.xml from all/deploy.last to your custom realm directory.

Repeat these steps on all cluster instances.

Run the JBoss cluster server instances using

run -c [realm_id] -b 0.0.0.0

Note: If your cluster instance binds to localhost/127.0.0.1, you could bind to your actual IP

run -c [realm_id] -b x.x.x.x

You could read more at JBoss Clustering chapter