Home Dashboard Directory Help
Search

CLR TVFs Are Not Gracefully Handled During AppDomain Recycles by Adam Machanic


Status: 

Closed
 as Won't Fix Help for as Won't Fix


18
0
Sign in
to vote
Type: Bug
ID: 765930
Opened: 10/3/2012 8:41:29 AM
Access Restriction: Public
0
Workaround(s)
view
3
User(s) can reproduce this bug

Description

When an AppDomain recycle occurs, most CLR module types are able to gracefully handle the situation: in-flight requests continue on the old AppDomain, new requests go to the new AppDomain, and eventually when all of the old requests are complete the old AppDomain is disposed of. This creates a more reliable and robust environment and keeps end-users from seeing exceptions when the server needs to do some housecleaning.

Unfortunately, this graceful handling is not done for TVFs. If a table-valued function is running and a recycle occurs, the function will immediately be aborted. Even worse, it will send the user a confusing and very misleading exception:

Msg 10316, Level 16, State 1, Line 2
The app domain with specified version id (4) was unloaded due to memory pressure and could not be found.

CLR TVFs are, in my experience, both the most useful -- by far -- of the available SQLCLR module types, and are probably also the most frequently used. Putting such functionality into a less robust, less reliable bucket is a major disservice to SQL Server developers and end users of SQL Server based solutions.
Details
Sign in to post a comment.
Posted by Microsoft on 2/27/2013 at 12:57 PM
Hello Adam,
Thanks for reporting the issue. We looked at this and behavior has existed in previous versions of SQL Server. And given the other high priority requests in our pipeline, fixing this issue is not a priority for us at the moment. I understand the pain and hopefully we can look at it in the future if our business priorities change.

--
Umachandar, SQL Programmability Team
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
abort_functions.cs 10/3/2012 773 bytes
tvf_abort.sql 10/3/2012 9 KB