<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Technotrance, Illusions and Perspectives &#187; caching</title>
	<atom:link href="http://myblog.shriharisc.com/tag/caching/feed/" rel="self" type="application/rss+xml" />
	<link>http://myblog.shriharisc.com</link>
	<description>A dose of everyday bruises with Java/JEE</description>
	<lastBuildDate>Mon, 02 Aug 2010 17:45:42 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Tip: Cached Associations in Hibernate Caching</title>
		<link>http://myblog.shriharisc.com/2009/11/10/tip-cached-associations-in-hibernate-caching/</link>
		<comments>http://myblog.shriharisc.com/2009/11/10/tip-cached-associations-in-hibernate-caching/#comments</comments>
		<pubDate>Tue, 10 Nov 2009 18:36:25 +0000</pubDate>
		<dc:creator>Shrihari</dc:creator>
				<category><![CDATA[jee-light]]></category>
		<category><![CDATA[caching]]></category>
		<category><![CDATA[hibernate]]></category>

		<guid isPermaLink="false">http://shriharisc.com/?p=3</guid>
		<description><![CDATA[In cases of deep rooted (entity objects with association chaining with other entity objects), there are N+1 select problem, where the chain of associated entity objects are queried and loaded into Hibernate Session from the database, everytime the master entity is loaded. To solve this problem, one should follow these practices:
1) Define the caching strategy [...]]]></description>
			<content:encoded><![CDATA[<p>In cases of deep rooted (entity objects with association chaining with other entity objects), there are N+1 select problem, where the chain of associated entity objects are queried and loaded into Hibernate Session from the database, everytime the master entity is loaded. To solve this problem, one should follow these practices:</p>
<p>1) Define the caching strategy on both the associated entity objects along the association chain.<br />
2) Deactivate the lazy-loading on the association link. One has to be selective in choosing association links for deactivating lazy loading.<br />
3) Define the caching strategy on the association link.</p>
]]></content:encoded>
			<wfw:commentRss>http://myblog.shriharisc.com/2009/11/10/tip-cached-associations-in-hibernate-caching/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>A Quick note about Hibernate Caching</title>
		<link>http://myblog.shriharisc.com/2009/09/14/a-quick-note-about-hibernate-caching/</link>
		<comments>http://myblog.shriharisc.com/2009/09/14/a-quick-note-about-hibernate-caching/#comments</comments>
		<pubDate>Mon, 14 Sep 2009 16:32:43 +0000</pubDate>
		<dc:creator>Shrihari</dc:creator>
				<category><![CDATA[java-internals]]></category>
		<category><![CDATA[caching]]></category>
		<category><![CDATA[hibernate]]></category>
		<category><![CDATA[query-cache]]></category>

		<guid isPermaLink="false">http://schakrap.wordpress.com/?p=111</guid>
		<description><![CDATA[1)    First Level Cache (Transaction Layer)
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 [...]]]></description>
			<content:encoded><![CDATA[<p style="margin-right:0;text-align:left;" dir="ltr"><span style="text-decoration:underline;"><strong><em>1)    First Level Cache (Transaction Layer)</em></strong></span></p>
<p style="margin-right:0;text-align:left;" dir="ltr">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.<br />
b) All queries (state of an entity, updates) in the cache gets flushed / committed to the database only when  Transaction context ends (i.e.) <strong>getTransaction().commit</strong> is called.<br />
c) Always used and cannot be turned off.</p>
<p style="margin-right:0;text-align:left;" dir="ltr"><span style="text-decoration:underline;"><strong><em>2)    Second Level Cache (Application Layer)</em></strong></span></p>
<p style="margin-right:0;text-align:left;" dir="ltr">a) Associated with a Hibernate&#8217;s SessionFactory (process scoped). Enabled by default in Hibernate 3 and uses <strong>EHCache</strong> as default cache provider.<br />
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.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">Syntax : { id ­&gt; { atribute1, attribute2, attribute3,{attribute41, attribute42},&#8230; } }</p>
<p style="margin-right:0;text-align:left;" dir="ltr"><span style="text-decoration:underline;"><strong><em>3)   Query cache (</em></strong><strong>org.hibernate.cache.QueryCache)</strong></span></p>
<p style="margin-right:0;text-align:left;" dir="ltr">a) Defines 2 cache regions : <strong>org.hibernate.cache.StandardQueryCache</strong> (stores query with parameters as cache key) and <strong>org.hibernate.cache.UpdateTimestampsCache</strong> (keeps stale query results of last results fetch). Both the cache regions are evicted when the entity related to the cacheable query is updated.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">Syntax : { query,{parameters}} &#8212;&gt; {id of cached entity}</p>
<p style="margin-right:0;text-align:left;" dir="ltr">b) A specific query results are cached, by specifying setCacheable(true) on Session&#8217;s Query handle.</p>
<div id="_mcePaste" style="overflow:hidden;position:absolute;left:-10000px;top:0;width:1px;height:1px;">
<p style="margin-right:0;text-align:left;" dir="ltr"><em>1)    First Level Cache (Transaction Layer)</em></p>
<p style="margin-right:0;text-align:left;" dir="ltr">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.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">b) All queries (state of an entity, updates) in the cache gets flushed / committed to the database only when  Transaction context ends (i.e.) <strong>getTransaction().commit</strong> is called.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">c) Always used and cannot be turned off.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">
<p style="margin-right:0;text-align:left;" dir="ltr"><em>2)    Second Level Cache (Application Layer)</em></p>
<p style="margin-right:0;text-align:left;" dir="ltr">a) Associated with a Hibernate&#8217;s SessionFactory (process scoped). Enabled by default in Hibernate 3 and uses <strong>EHCache</strong> as default cache provider.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">
<p style="margin-right:0;text-align:left;" dir="ltr">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.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">
<p style="margin-right:0;text-align:left;" dir="ltr">Syntax : { id ­&gt; { atribute1, attribute2, attribute3,{attribute41, attribute42},&#8230; } }</p>
<p style="margin-right:0;text-align:left;" dir="ltr">
<p style="margin-right:0;text-align:left;" dir="ltr"><em>3)   Query cache (</em><strong>org.hibernate.cache.QueryCache</strong>)</p>
<p style="margin-right:0;text-align:left;" dir="ltr">
<p style="margin-right:0;text-align:left;" dir="ltr">a) Defines 2 cache regions : <strong>org.hibernate.cache.StandardQueryCache</strong> (stores query with parameters as cache key) and <strong>org.hibernate.cache.UpdateTimestampsCache</strong> (keeps stale query results of last results fetch). Both the cache regions are evicted when the entity related to the cacheable query is updated.</p>
<p style="margin-right:0;text-align:left;" dir="ltr">Syntax : { query,{parameters}} &#8212;&gt; {id of cached entity}</p>
<p style="margin-right:0;text-align:left;" dir="ltr">b) A specific query results are cached, by specifying setCacheable(true) on session&#8217;s Query handle.</p>
</div>
]]></content:encoded>
			<wfw:commentRss>http://myblog.shriharisc.com/2009/09/14/a-quick-note-about-hibernate-caching/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
