OrmLite based ServiceStack.Messaging implementation

ServiceStack.OrmLite
1

I been working on an OrmLite based Messaging implementation this weekend. Its still a work in progress, but is working against Sqlite and SqlServer2012 so far, in single pass. Still need to get the background worker implemented. https://gist.github.com/rsafier/a54b0af50518a6c8e9b5
.
I found this Extention method to be effective in dealing with the dynamic table names I required:

static object ExecWithAlias<T>(string table, Func<object> fn)
    {
        var modelDef = typeof(T).GetModelMetadata();
        lock (modelDef)
        {
            var hold = modelDef.Alias;
            try
            {
                modelDef.Alias = table;
                return fn();
            }
            finally
            {
                modelDef.Alias = hold;
            }
        }
    }

But initially I trying to make each queue/table name a distinct type so there would be no locking necessary. As written Message is locked to a single operation at an instant because the other code will block. Its not a big deal for my current usage, it easily is running a few hundred messages per second. I was wondering if I was overlooking a better way of “cloning” a type.

2

There’s no other “easy” way to change the Table name at runtime other than using the Custom SQL API’s to construct your own query with the preferred table name. Another “Hack” would be to use Reflection.Emit to create a new Type at runtime that inherits the existing Type but contains an [Alias] attribute, although it’s not performant to create a new type per query.

3

As it stands, this implementation is an order of magnitude quicker then I require right now. If I get near that limit I can refactor or convince the powers that be that RabbitMQ might be a better option.

I really don’t have any desire to go down the Reflect.Emit road without a legit reason to. If cached, a dynamically created type should only add some bloat to the startup, and the rare occurrence of a new queue name that wasn’t part of the registered queues at startup.