Python and Ruby lovers will see now that they can use all the library and features of the .NET platform programming in their favorite scripting language. Since both of them are object oriented, you can now write fully fledged apps using either of them.

However, there’s another interesting application for IronPython and IronRuby: adding scripting support for your existing .NET applications. This can be a very useful and powerful way to extend your applications and give the user freedom to program their own mini programs, scripts or whatever in your applications. It could be good for defining rules, assigning and calculating values, etc.

I’ll provide a simple class you can use to add scripting to your application. I’ll use IronPython in this example.

First of all, you have to download IronPython and install it, and add the references to the assemblies on your project references.

The usual way to proceed in those cases is to provide the user of some local variables you give them access to, execute the script, and then recover the values of those or new variables. To do so, You can use a class similar to this one:

using System;
using System.Collections.Generic;
using System.Text;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
using Microsoft.Scripting;
 
namespace Scripting
{
	internal class PythonEngine
	{
        ScriptEngine m_engine;
        ExceptionOperations m_exceptionOperations;
        SortedDictionary<string, object> m_inputVariables;
        string m_script;
 
        internal PythonEngine()
        {
            m_engine = Python.CreateEngine();
            m_exceptionOperations = m_engine.GetService<ExceptionOperations>();
        }
 
        internal SortedDictionary<string, object> ScriptVariables
        {
            set { m_inputVariables = value; }
        }
 
        internal string Script
        {
            set { m_script = value; }
        }
 
        internal ExceptionOperations ExceptionOperations
        {
            get { return m_exceptionOperations; }
        }
 
        internal SortedDictionary<string, object> Execute()
        {
            //Create structures
            SourceCodeKind sc = SourceCodeKind.Statements;
            ScriptSource source = m_engine.CreateScriptSourceFromString(m_script, sc);
            ScriptScope scope = m_engine.CreateScope();
            //Fill input variables
            foreach (KeyValuePair<string, object> variable in m_inputVariables)
            {
                scope.SetVariable(variable.Key, variable.Value);
            }
            SortedDictionary<string, object> outputVariables = new SortedDictionary<string, object>();
            //Execute the script
            try
            {
                source.Execute(scope);
                //Recover variables
                foreach (string variable in scope.GetVariableNames())
                {
                    outputVariables.Add(variable, scope.GetVariable(variable));
                }
            }
            catch (Exception e)
            {
                string error = m_exceptionOperations.FormatException(e);
                //Do something with the pretty printed error
                throw;
            }
            return outputVariables;
        }
	}
}

Usage of this class is pretty simple. You have to provide the object the script you want to execute and the input variables the script will have available as local variables. Once this is done, you have to call the Execute method, and this method will either return the output variables of the execution of the resulting script, or throw an exception.

Cropped ComboBox

This is annoying because users cannot read properly the information. To solve that problem, all we have to do is derive the ComboBox class and override the DropDown event as follows:

public class ComboBoxEx : ComboBox
{
	public ComboBoxEx()
		: base()
	{
		DropDown += new EventHandler(event_DropDown);
	}
 
	void event_DropDown(object sender, EventArgs e)
	{
		try
		{
			ComboBox comboBox = (ComboBox)sender; // Catch the combo firing this event
			int width = comboBox.Width; // Current width for ComboBox
			Graphics g = comboBox.CreateGraphics(); // Get graphics for ComboBox
			Font font = comboBox.Font; // Doesn't change original font
 
			//checks if a scrollbar will be displayed.
			int vertScrollBarWidth;
			if (comboBox.Items.Count > comboBox.MaxDropDownItems)
			}
				//If yes, then get its width to adjust the size of the drop down list.
				vertScrollBarWidth = SystemInformation.VerticalScrollBarWidth;
			}
			else
			{
				//Otherwise set to 0
				vertScrollBarWidth = 0;
			}
			//Loop through list items and check size of each items.
			//set the width of the drop down list to the width of the largest item.
			int newWidth;
			foreach (string s in comboBox.Items)
			{
				if (s != null)
				{
					newWidth = (int)g.MeasureString(s.Trim(), font).Width + vertScrollBarWidth;
					if (width < newWidth)
						width = newWidth;
				}
			}
			// Finally, adjust the new width
			comboBox.DropDownWidth = width;
		}
		catch {  }
	}   
}

The following picture shows the results of using the above control instead of the default one:

Non Cropped ComboBox

Imagine you want to list all the files on C: on the SQL Server Windows host: you could write a T-SQL statement like this one:

EXECUTE master..xp_cmdshell 'dir c:'

This stored procedure, however, is a very dangerous one, as it would allow to execute harmful code. This is the reason why it’s disabled by default. Even when enabled, only users on the sysadmin role can use it.

If you ever need some users the ability to run only some specific commands with xp_cmdshell, you can use the method I’ll explain below, making use of the EXECUTE AS modifier of the stored procedure definitions in T-SQL.

The proposed solution involves five steps:

• Enabling the xp_cmdshell extended procedure.
• Adding a procedure on the database with the EXECUTE AS modifier as an administrator, controlling which commands are allowed to be executed.
• Modifying or creating the xp_cmdshell_proxy_account, associating it to a user with sysadmin privileges.
• Giving the user(s) you want the EXECUTE privileges to the procedure.
• Grant the proxy account user the privilege to log on as a batch in the Windows server.

The execution of xp_cmdshell must be enabled on the SQL Server. This can be done through the SQL Surface Area Configuration utility or by code. Refer to Figure below on how to activate xp_cmdshell through the SQL Surface Area Configuration.

SQL Surface Area

To enable xp_cmdshell using SQL code, use the sentences below:

EXEC master.dbo.sp_configure 'show advanced options', 1
RECONFIGURE
EXEC master.dbo.sp_configure 'xp_cmdshell', 1
RECONFIGURE

This will allow users of the sysadmin role, and no one else, to execute xp_cmdshell.

Now we have to create a special stored procedure that will control the actions used as parameters to xp_cmdshell. This will allow the administrators of the database to have control over which commands they allow to be executed on their servers. The most important part of this procedure is the EXECUTE AS OWNER modifier. By using this modifier, everyone that runs that procedure will be able to run it as if it was the owner of the database, thus having execute permissions to xp_cmdshell (we’re assuming the procedure will be created in the master schema. By granting execute permissions on that procedure, you will allow specific users an indirect way to call the xp_cmdshell.

Using this method, only the users of the sysadmin role will be able to execute xp_cmdshell, and only the users you grant EXECUTE permissions on the stored procedure will be able to execute the specific commands that you allow.

To insert the store procedure, log in as a sysadmin on the database and create it with the EXECUTE AS OWNER modifier on it.

For the above procedure to work on non sysadmin accounts there is another step that has to be done. By default, even if you have permissions on the store procedure, you won’t be able to execute it if you’re not on the sysadmin role. This is because those users need a proxy account that is used as the account in which the xp_cmdshell is executed.

So, for this procedure to work, you must create or modify the xp_cmdshell_proxy_account with a user within the sysadmin role. To setup this account, proceed with the code below:

EXEC sp_xp_cmdshell_proxy_account 'MyDomain\MyUserName', 'myDomainPassword'

If the above code does not work, try this one:

CREATE credential ##xp_cmdshell_proxy_account## with identity = 'Domain\DomainUser', secret =  password'

After the procedure and the proxy account have been set, the users we want to be able to execute the procedure must be granted EXECUTE permission on it. To do so, execute this statement for every user you want to grant permissions:

GRANT EXECUTE ON Tango_xp_cmdshell TO <username>;
GO

To grant this permission, use the Local Security Settings on the Administrative Tools interface of the Windows Control Panel. Once there locate the property shown on the screenshot and add the user you gave permissions to the user list.

Local Security Policy

Note that enabling the xp_cmdshell command may still have some security implications, so try to avoid it when possible.

So, what’s the matter with StringBuilders in C#?

It seems the same thing happens with Strings, C# and Java. Here is a copy paste from the MSDN web page about the StringBuilder usage:

The String object is immutable. Every time you use one of the methods in the System.String class, you create a new string object in memory, which requires a new allocation of space for that new object. In situations where you need to perform repeated modifications to a string, the overhead associated with creating a new String object can be costly. The System.Text.StringBuilder class can be used when you want to modify a string without creating a new object. For example, using the StringBuilder class can boost performance when concatenating many strings together in a loop.

So I decided to run some tests to see how much it was worth to change my code to use the StringBuilder class, because I use the string ‘+’ operator a lot in my program, and the results are simply amazing. Here you can find a chart comparing the times it took to concatenate a given number of strings using both methods. See for yourself and then… use StringBuilders from now on!

String usage

StringBuilder usage

Here’s the source code i used if you want to try it for yourself:

using System;
using System.Collections.Generic;
using System.Text;
 
using Adapdev.Diagnostics;
 
namespace SBuilder
{
    class Program
    {
        static void Main(string[] args)
        {
            HiPerfTimer timer = new HiPerfTimer();
            for (int i = 0; i < 100; i++)
            {
                StringBuilder sb = new StringBuilder();
                timer.Start();
                for (int j = 0; j < 1000 <strong> i; j++)
                {
                    sb.Append(j);
                }
                timer.Stop();
                double timeStringBuilder = timer.Duration;
 
                string s = string.Empty;
                timer.Start();
                for (int j = 0; j < 1000 </strong> i; j++)
                {
                    s += j;
                }
                timer.Stop();
                double timeString = timer.Duration;
 
                StringBuilder line = new StringBuilder();
                line.Append(1000 * i);
                line.Append(";");
                line.Append(timeStringBuilder);
                line.Append(";");
                line.Append(timeString);
                System.Console.WriteLine(line.ToString());
            }
        }
    }
}

You can download the external timer classes from The Code Project.

One of the most interesting features of any good database engine is what we call concurrency. Concurrency means than the database engine should be able to perform a lot of data operations at the same time. This leads to some interesting problems that have a critical impact on another of the features that any database engine must ensure: data consistency.

Sometimes you need to perform more than one non atomic operation in a database that only make sense in a block. This is, all those operations should be executed from the start to the end without any other interference from other operations, because those other operations may have a non desired impact in your operations. The simulation of the atomic execution of more than one operation in databases is done by transactions. When you embrace a set of operations in a transaction, you are telling the database engine that you want those operations to be executed as if they were executed in an isolated mode, this is, with no interference from other operations.

While this might seem easy to accomplish, it can also have a big negative performance impact, because you can’t plan on executing all the transactions that arrive at the same time in a sequential way, at least not if you want your database engine to be slow, very slow.

This is where locks ans isolation levels intervene. Locks are protections made to some resources to allow or forbid further access to those resources by another processes. An exclusive lock, for example, done by a process, means that no other process should be able to access that resource until the first process has freed the lock. There are a lot of different locks in SQL Server, which you can review at http://msdn2.microsoft.com/en-us/library/ms175519.aspx.

One of the problems we can face when working with transactions is the well known repeatable read. Suppose a process A starts a transaction and reads a registry with a select clause in a table. After that, another transaction comes in and modifies that data. The first transaction reads the same data again and gets a different value, becuase it was modified by the second transaction. This is inconsistent, because as we are executing a set of operations inside a transaction, we expect them to be executed as if no one else was modifying the data we need to use.

Because of that, there’s a special isolation level called, precisely, Repeatable Read, which has a locking policy to avoid those problems. But be careful with this, since this can cause a nasty deadlock in your SQL Server if used the wrong way.

A deadlock is a special situation where two or more transactions are waiting each other. Imagine trasaction A starts some operations and locks some resources. Later, transaction B comes in, locks another set of resources, and then tries to access resources locked by A, so it waits for A to free those resources. After that, A tries to lock resources locked by B and wait for B to free them. A is waiting for B to free its resources, and B is waiting for A to do the very same thing. We have a deadlock. One of the transactions must be killed by the database engine and rolled back so the other one can continue. Altough this is something you might be able to control by code and issue a relaunch of the killed transaction, this is something usually not desired.

I’m going to talk now about a deadlock you may face when using the Repeatable Read transaction isolation level with SQL Server 2005. Imagine you have two transactions that do the same thing: read a value, modify it, and read it again. Note that you will be modifying the value, but you set the isolation mode to Repeatable Read (this is, setting the wrong isolation mode by mistake or by ignorance). Transaction A starts and reads the value. SQL Server puts a shared lock on that resource. Transaction B starts and reads the value. Because the lock in A was shared, B can also read that value, gaining a shared lock too. Now transaction B tries to write that value. Because the shared lock put by A was read only, B has to wait for A to release its shared lock to be able to gain write acces to it, so it blocks. After that, A tries to write the value, and because now it’s transaction B that has a shared lock on the resource, it has to wait too. And there it is, the deadlock.

The key in avoiding this is that, although we perform a read-write-read operation, we don’t need the second read to be the same as the first, because we are modifying that resource. In this case, the lock our transactions should get is an update lock, which knows that we’ll be modifying that data after having read it. This way, when transaction A locks the resource, the lock will not be shared, so transaction B will have to wait for A to write the new value before B gets the lock, thus avoiding the deadlock. Another option is use an isolation level that frees the locks just after having read the value, and not maintaining it until the next update.

The conclusion to this is: be careful when working with transactions on which isolation level you use on them, and be sure you’re using the right one if you don’t want to have bug reports when a lof of concurrency starts to stress the database engine!

Imagine you are developing a rails application. Usually you have:

• a terminal with the server to see what petitions are received.
• a terminal with a tail of development.log to see what happens with the database.
• a terminal with a tail of test.log if you are testing something.

This are a lot of windows… And the other day one friends was very happy and after asking for a while I discovered that the reason was the simple line showed above… With only one Ctrl+C you can kill all this processes

script/server & tail -f log/development.log & tail -f log/test.log & tail -f ; jobs -p | awk '{print "kill -2 " $0}' | sh

Today I’ll be discussing a design pattern called Double Check, which can be widely used to manage the resource access, elimination and initialization in a safe thread way.

Consider another common design pattern: the Singleton Pattern. A singleton is a special class which is allowed to have one and only one instance in a program. This pattern can be used in a variety of ways, one of the most usual one is to store global program information, which, as its name states, is global and unique to the application, so having more than one instance of that class would have the burden to mantain them synchronized, or even more nasty consequences.

There are different ways to implement a singleton class. I will focus on C#, but the example shown here could be easily extended to other languages such as C++ or Java. The trick on the pattern consists on declaring the class constructor private. This way we can be sure no one will be creating new instances of that class at will. After having done this, we have to provide a public method, which usually has the name getInstance, that will be the one actually creating this item and returning it to the caller.

The code would look similar to this one:

public sealed class Singleton
{
    private static Singleton instance = null;
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

Another way to create this singleton class would be doing the instantiation of the private variable on the class itself and not on the getInstance method, but this second way gives us a lazy initialization, so the variable is actually instantiated only when it’s needed, and never before (who knows, maybe we will never need it in some circumstances).

This implementation is perfect… as long as this method isn’t called twice (or more) at the same time. Consider what would happen if two threads requested an instance of the singleton class: both threads would check for the instance being null, and both threads would create the instance. That would sure lead to an unknown behaviour, and more than one instance of the class would be in the program, which is exactly what we wanted to avoid.

The first solution that comes in mind is to lock the method so multiple threads must wait to enter the method and get the singleton instance. It would look like this:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            lock(semaphore);
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

This way we ensure that if n threads try to access the routine at the same time, only one will be initializing the singleton instance, since when the others gain the access to the method again, that instance won’t be null anymore. However, even if this solution is valid and works, it has a serious performance problem. Consider the situation where the instance has been already created. Then more than one thread access the routine again to get that instance. What will happen is that those threads will have to block and wait for other threads to finish, even if the instance is not null, so in any case will be created again. Conclusion: we are blocking threads that don’t need to be blocked. “Ok, you may say, we will put the lock inside the if clause, and we’ll have the issue resolved“. Let’s take a look at this solution:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock(semaphore);
                instance = new Singleton();
            }
            return instance;
        }
    }
}

You don’t have to be a genious to see that this is not working, either. It will work after the instance has been created, because the threads won’t be entering the if clause, and they won’t be blocked. But if we are in the same situation as the described in the first place –this is, more than one thread entering the method before the instance has been created–, we have the same problem we had before: the singleton will be created more than once.

The final solution is simple: check again for the variable being null! This is why this pattern is called Double Check. The final code would look like this one:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock(semaphore);
                if (instance == null)
                    instance = new Singleton();
            }
            return instance;
        }
    }
}

This way, we allow the threads to pass by the if clause if the instance has been already instantiated, and if it has not, the threads will get blocked, and the first one to gain access to the method will do the instantiation. Further threads will check again against the instance being null or not, so it won’t be created again.

Altough this pattern may be implemented similarly in other languages, be aware that, as I said before, a lot of them were never intended to deal with multithreading, and that compiler optimizations may give you code which is not really thread safe, or that actually is not optimized. Here you have a link discussing this issue with Java and C++: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.