<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Application Performance: Open Session In View Design Pattern</title>
	<atom:link href="http://www.cirrusabs.com/blog/application-performance-open-session-in-view-design-pattern/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cirrusabs.com/blog/application-performance-open-session-in-view-design-pattern/</link>
	<description>NetCentered &#38; Internet Marketing Concepts.</description>
	<lastBuildDate>Mon, 30 Jan 2012 18:16:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
	<item>
		<title>By: Keith</title>
		<link>http://www.cirrusabs.com/blog/application-performance-open-session-in-view-design-pattern/comment-page-1/#comment-397</link>
		<dc:creator>Keith</dc:creator>
		<pubDate>Sat, 23 Apr 2011 13:04:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.cirrusabs.com/blog/?p=191#comment-397</guid>
		<description>The pattern that you describe here does not scale well.  Best practices indicate that when it comes to database connections we should &quot;open late, close early&quot;.  The goal: keep connection lifetimes as short as possible.  This pattern would result in a much higher rate of open connections to the database on a high volume site as you are keeping your connection open for the lifetime of the request whether it is being used or not.

The problem that you tackle here is very important.  It is important that the solution to this problem also address connection lifetime.  I have used a number of approaches together to assist in this mitigation:

1)  Enable connection pooling.  This will reduce the overhead of acquiring connections
2)  Cache meta data aggressively.  This can eliminate alot of the database chattiness in applications
3)  Consolidate retrieval of business data into a common phase that your architecture controls.  Within the &quot;data retrieval&quot; phase, create and share a single connection where applicable.

I am the principal architect of customer facing web applications for an huge international bank.  Our daily site volumes are in a word... staggering.  In our environment we also use a asynchronous, portal based, component architecture.  In other words, our portlets retrieve their content asynchronously using AJAX.  In such an architecture, keeping a database connection alive is not what you want.  We have found that the two most signficant data retrieval enhancement that we can make are the first two options that I listed above.</description>
		<content:encoded><![CDATA[<p>The pattern that you describe here does not scale well.  Best practices indicate that when it comes to database connections we should &#8220;open late, close early&#8221;.  The goal: keep connection lifetimes as short as possible.  This pattern would result in a much higher rate of open connections to the database on a high volume site as you are keeping your connection open for the lifetime of the request whether it is being used or not.</p>
<p>The problem that you tackle here is very important.  It is important that the solution to this problem also address connection lifetime.  I have used a number of approaches together to assist in this mitigation:</p>
<p>1)  Enable connection pooling.  This will reduce the overhead of acquiring connections<br />
2)  Cache meta data aggressively.  This can eliminate alot of the database chattiness in applications<br />
3)  Consolidate retrieval of business data into a common phase that your architecture controls.  Within the &#8220;data retrieval&#8221; phase, create and share a single connection where applicable.</p>
<p>I am the principal architect of customer facing web applications for an huge international bank.  Our daily site volumes are in a word&#8230; staggering.  In our environment we also use a asynchronous, portal based, component architecture.  In other words, our portlets retrieve their content asynchronously using AJAX.  In such an architecture, keeping a database connection alive is not what you want.  We have found that the two most signficant data retrieval enhancement that we can make are the first two options that I listed above.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

