Monday, December 13, 2004 - Posts
Sorry guys, but I won't be posting much about the next module in the course since I've been "promoted" to guest code monkey for the guys. That'll teach me to sit in the front row!
Bob started this morning by talking about the CLR in SQL Server. Heres some highlights:
- He talked about the differences between in-process and out-of-processing hosting. Seen as a good thing because it allows SQL Server to manage resources vs. products like Oracle that pass the call to a bolted-on run time that manage themselves.
- If the CLR features aren't used, the CLR hosting never takes place, so its safer by default. You can see in this SQL logs. Loaded on first invocation (gave an example of loading by using create assembly). select * from sys.dm_os_memory_clerks can show you how much memory the CLR is taking up.
- Once loaded, the CLR isn't unloaded until the service process dies.
- CLR Service packs likely mean SQL Server Service packs
- Use sp_configure 'clr enabled' 0 to disable to the CLR, or 1 to enable. sp_configure 'show advanced options' will report if the CLR is enabled with about a 1,000 other things...
- Talked about the differences ICLRRuntimeHost, the SQL takes control of the CLR using SetHostControl hooks. SQL Server controls the CLR through GetHostManager. SQL Server controls the four tasks of resource allocation, exceptional conditions, code and class loading and security particulars. By the way, you can doing in-processing in your allocations if you like using the same interfaces.
- Parts of the Framework Library (FX) aren't available since the SQL team does a more stringent review of the bits before the SQLCLR will be allowed to load them. This is part of the reason that J# isn't available for writing CLR objects. Code written by third-parties and users don't have to pass this muster, they just pass the normal three levels. Although the aren't on the explicit list, System.Transactions and System.Data.OracleClient are considered "blessed."
- Talk about how CLR 2.0 improves on runtime reliability. "The only does bad things if the database lets it."
- Great demo of how SQL inspects CLR assemblies with reflection.
- Remember that mutable statics are shared as a singleton per app-domain.
- App Domains are spun up by Assembly Owner, this complicates sharing assemblies
- Unsafe Assemblies must be ready to deal with thread.abort.
- Example of a dangerous attribute: [STAThread]. LOL!
- Should always decorate unsafe code with HostProtectionAttributes to prevent problems with a safe assembly calling into an unsafe assembly.
- Did a proof that once an assembly is a cataloged, you don't need the DLL.
- If you deploy in development state, the PDB, source and project are loaded into sys.assembly_files. In fact, you really could whatever you like, but that could lead to potential problem with the source getting out of sync. Fun to watch with profiler.
- Assembly class names are always sensitve, even for VB.NET
- Bob had an brief but interesting rant on ANSI SQL part 13
Just a quick photo of the gang of three...
I'm feeling really lucky to be in Redmond this week -- over at the conference center for DevelopMentor's Guerilla SQL Server 2005. Bob is just kicking this mornings session off. I'll be blogging the stuff that strikes me as worth talking about over the next five days here.