Part 1: Let's talk about WCF

This will start a series about moving WCF configuration out of the typical application configuration files that are generated by Visual Studio and putting it somewhere, anywhere else, that is atypical of most systems. In this case, I will be showing how I was able to move it into a database.

You might ask why do this? For starters, this was a project for work. I fully support what this project's intentions and purpose was because it simplifies my life and the life customer support and the customers, even though there may exist people who will cringe at this (probably technical people who would see this as a bad idea, but see the disclaimer). Basically, the goal was to have a single point of configuration which would minimize work that would have to be done across multiple machines which share the same configuration, but each having its own copy.

For those new to WCF, it is Windows Communication Foundation. It's a framework for creating services, mostly web services and enterprise, and it's based on a client-server model. The server defines the operation contract, that is, what operations does the client have access to; and the data contract, that is, the data model the client and server expect from each other when communicating. In layman's terms, it's basically the server saying "We will communicate by speaking English and here are the commands and queries I will allow you to use". You can find the Microsoft page discussing WCF here.

So that's the very brief introduction. Next time, I'll go over the database side of things and what the application configuration looked like before and after I made my changes.

Disclaimer: I have limited knowledge of WCF in and of itself; I've done enough to know when something will work or when I should ask more questions. There could be design or security flaws in what I am doing here, but unfortunately for me, there was next to nothing about this on the Internet and at the moment there is nobody else on my team who understands WCF to this level. Also, my WCF intro could be completely wrong; if so I apologize for that. That being said, I welcome constructive criticism of my design decisions regarding this project (not my lack of WCF knowledge); post those in the comments.

Upcoming project - online recipe book

In my quest for expanding my culinary horizons, I have come to the realization that all my recipes exist in the form of a stack of folded papers, index cards, and miscellaneous clippings from various food packages and that all of these recipes are in no sort of order. They are not even in order by when I first made them since I shuffle them around when searching for a certain recipe which I plan to use.

While there exist solutions to this problem in the form of binders or little index card boxes, I either need to memorize recipes or have the physical medium present in order to view the recipe. Therefore, I am taking it upon myself to create website which will have the sole purpose (originally) of storing recipes.

You are probably thinking, why go to all that trouble? Well, for one, it would be a fun project for me to do in order to learn a new technology, as well as something that would have a practical purpose after its completion. As well as learning about the software life cycle from planning to deployment and maintenance. I also want to use this project as an opportunity for learning about different software management methodologies, the pros and cons of each, and the implications each style would have on a software product.

My hope is to have the site hosted for others to use as well and eventually add features, such as sending recipes between users. Because I will be planning the project on a per feature basis, I don't have a solid deployment date. My estimate is by mid-December I will have the first version ready to deploy.

Anyway, I don't expect everyone to understand the previous two paragraphs since some of it is industry jargon. However, if this is something that you would use, stay tuned for updates about the progress of this project.

Locking SQL databases

Have you ever wanted or needed to lock a table in an SQL database? It turns out that it's actually useful to do so, especially when testing software which assumes that all database queries automatically work correctly.

I found the below SQL script over at stackoverflow:

SELECT * FROM [dbo].[tableName] WITH (TABLOCKX, HOLDLOCK)

It will select everything from a table with an exclusive lock (using TABLOCKX) and it will hold the lock until the end of the transaction (using HOLDLOCK).

We can extend this by using

BEGIN TRANSACTION

SELECT * FROM [dbo].[tableName] WITH (TABLOCKX, HOLDLOCK)
WHERE 0 = 1

WAITFOR DELAY '00:09'

END TRANSACTION

The above will select 0 rows from the table (WHERE 0 = 1, which always evaluates false) and will hold an exclusive lock on the selected table for 9 minutes (using WAITFOR DELAY).

Practically, this can be useful for testing anything which may throw an exception in SQL. For instance, when testing a bulk insert which inserts hundreds of thousands of rows may take some time, especially if other transactions are taking place simultaneously, a table lock can simulate what would happen if the query timed out in a production environment.