OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
OpenEdge Data Management: DataServer for Microsoft SQL Server
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 4: Additional Features to Enhance <strong>Data</strong><strong>Server</strong> Per<strong>for</strong>mance<br />
Impact on commits in stored procedures<br />
Running a stored procedure in a separate connection changes the timing of changes<br />
being committed to the data source. When a stored procedure is run in a separate<br />
connection, changes not explicitly committed during the execution of the stored<br />
procedure are committed at the time the procedure handle is closed and the connection<br />
is recycled.<br />
Firehose and Fast Forward-Only Cursors<br />
Firehose cursors deliver a streamlined, unmanaged, client-side cursor-processing<br />
mechanism <strong>for</strong> handling result sets from a <strong>Data</strong><strong>Server</strong> query. When connection pooling<br />
is enabled, firehose cursors are the default mechanism <strong>for</strong> handling read-only results.<br />
If a firehose cursor is denied to an application, the <strong>Data</strong><strong>Server</strong> first attempts to<br />
substitute a Fast Forward-Only (FFO) server-side cursor with Auto-Fetch and<br />
Auto-Close attributes in its place. If the query cannot be handled by a FFO cursor, the<br />
cursor is further downgraded.<br />
Firehose cursors<br />
Firehose cursors are identified in <strong>Microsoft</strong> <strong>SQL</strong> <strong>Server</strong> as the default result set. A<br />
default result set is generated when the statement attributes of a cursor are left<br />
unchanged from their standard MS <strong>SQL</strong> defaults. The default result set allows rows<br />
from a query result to be pulled without locks in <strong>for</strong>ward-only sequence into a client-side<br />
cache. The default result set is referred to as a firehose cursor because it can “flood”<br />
the client with results. It is unencumbered by the cursor management necessary with<br />
server-side cursors.<br />
The following <strong>Data</strong><strong>Server</strong> operations are eligible <strong>for</strong> the firehose cursor<br />
implementation:<br />
• All NO-LOCK queries.<br />
• All SHARE-LOCK queries with transaction isolation level set to<br />
read-uncommitted.<br />
• Internal no-lock queries that populate the key cache <strong>for</strong> transaction-oriented<br />
operations.<br />
• All stored procedure result sets.<br />
• All send-sql-statement result sets.<br />
• Queries written with the QUERY-TUNING(SEPARATE-CONNECTION) keyword. When<br />
connection pooling is enabled, the QUERY-TUNING(SEPARATE-CONNECTION) is<br />
redundant.<br />
Note: Prepared statements associated with firehose cursors are now cached on a<br />
statement cache that is associated with the managed connection. Statement<br />
reuse may decrease based on the recycling of managed connections. To<br />
completely disable the prepared statement cache, use the following<br />
connection switch: “-Dsrv PRGRS_PREPCACHE,0”. For in<strong>for</strong>mation on<br />
monitoring the statement cache reuse, see the “Monitoring cursor and<br />
connection use” section on page 165.<br />
164 <strong>OpenEdge</strong> <strong>Data</strong> <strong>Management</strong>: <strong>Data</strong><strong>Server</strong> <strong>for</strong> <strong>Microsoft</strong> <strong>SQL</strong> <strong>Server</strong>
Change language