Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,582
|
Comments: 51,212
Privacy Policy · Terms
filter by tags archive
time to read 1 min | 188 words

Oren Ellenbogen has posted about generic constraints in the case where you have both an interface and a common base class. I tend to use the same Interface + Default base class often enough in my code. 

The issue I have with this is whatever the interfaace is even needed? I often find myself extending only from the base class and never directly from the interface.

Take for instance the MethodRecorderBase and IMethodRecorder from Rhino Mocks. Everythings works against IMethodRecorder, but all the concrete classes are decendants of MethodRecorderBase. In this case, whenever I need to add a method to the Method Recorders family, I need to update both the interface and base class (and maybe the sub classes).

Just to be clear, I'm not saying the the general principal is wrong, it is a defintely a Good Thing in certain cases (ICollection & CollectionBase come to mind), but I wonder about its usage when you start with new code.

Isn't this a violation of both DRY and YAGNI?

time to read 1 min | 156 words

Yesterday I was at the C# User Group meeting. The lecturer was Dan Amiga, and the subject was ASP.Net Hard Core.

I came out of the meeting completely satisfied. Dan has gone over quite a lot of subjects, some of them I was already using, but he went deeper into the stuff. And many of those things I wasn't even aware of. Very good stuff, overall, and I really enjoyed it.

The nicest tidbit in the entire lecture was how to package a User Control as a DLL. It is a bi t of a  hack, but it works. Compile the web site with ASPNET COMPILER using fixed names and use the DLL.

 

The part about Vendor Lock In was when we tried to disperse. The elevator absolutely refused to take us all down, so we had to go down  in very small groups, so the elevators wouldn't panic and decide that this isn't some mass exodus to leave Microsoft J.

time to read 12 min | 2240 words

My last post about static variables caused a few comments, so I think that it needs more clarifications. The first thing is to understand what I am talking about when I'm thinking about thread safety.

  • Thread safety issue when you initialize something (which I actually run into today :-) ) where two threads try to access a lazy resource and end up initializing it twice. This is relatively easy to solve using static constructor or static initializators. They are guaranteed to run before somebody access this field for the first time, and they are guaranteed to run once and only once.
    public static readonly IDbConnection Connection = CreateAndOpenConnection(); 

    This is not the kind of thread safety I am talking about here.
  • Thread safety when you use a variable from multiply threads. This is usually what worries me. It worries me because I often work in multiply threads, and because I usually work in the web, where thread affinaty in not something I can rely on. Check out the sample code below.

First, we define the database class:

public class DataBase

{

       public static SqlConnection Connection = CreateAndOpenConnection();

 

       private static SqlConnection CreateAndOpenConnection()

       {

              SqlConnection sqlConnection = new SqlConnection("Data Source=localhost;Initial Catalog=test;Integrated Security=True");

              sqlConnection.Open();

              return sqlConnection;

       }

}

Notice that the SqlConnection variable is public static, and in its documentation there is a comment saying that public static variables of this type are safe for multi threading. The documentation is even current in this instance. It is just talking about access the variable itself, not working with it.

Update: There is something wrong in my reading comprehension. Sergey posted a comment about the above sentence. I read it wrong. It is not public static memebers of this type that I define. It is public static members that this type has. Damn! Sorry about the mistake.

Here is a simple method that works with this object. Notice that there is a slight delay to simulate heavier load:

private static void GetData()

{

       using (IDbCommand command = DataBase.Connection.CreateCommand())

       {

              command.CommandText = "SELECT * FROM Persons";

              using(IDataReader reader = command.ExecuteReader())

              {

                     Thread.Sleep(500);

                     while(reader.Read())

                     {

                           Console.WriteLine(reader.GetValue(0));

                     }

              }

       }

}

Pretty standard stuff so far, isn't it? Now, let us look at our Main method:

static void Main(string[] args)

{

       new Thread(GetData).Start();

       new Thread(GetData).Start();

       Console.ReadKey();

}

We are accessing the GetData() method from two different threads, and both threads end up using the same instance of SqlConnection.

Can you guess what the result will be?

In my tests, it consistently throws one of these exceptions:

  • Invalid attempt to Read when reader is closed.
  • There is already an open DataReader associated with this Command which must be closed first.

We have got ourself a threading problem...

Clarification: The issue that I am raising here is a basic one, I know. I'm trying to reach some place and I want to go all the way, so I wouldn't lose anything along the way. It should be clearer later. (Oh, and the static connection property is evil. It is just the simplest example I could think about).

Static Issues

time to read 2 min | 349 words

The easiest way to get access to something, is to make is static. This way, you can to it from everywhere in the application, without having to instansiate it every place you need it.

Consider this piece of code, which saves an order to the database:

using(IDbCommand command = DataBase.Connection.CreateCommand())

{

    command.CommandText = "INSERT INTO Customers VALUES('New','Customer'";

    command.ExecuteNonQuery();

}

Here is how we define the DataBase class:

public class DataBase

{

    static IDbConection connection;

 

    public static IDbConnection Connection

    {

        get

        {

            if ( connection == null)

            {

                connection = CreateAndOpenConnection();

            }

            return connection;

        }

    }

}

Even ignoring the pitfall of leaving connections open for a long time, can you see the problem?

What happen if we are using this on the web, and two users are trying to view a page at the same time? One of them is likely to get the "data reader is already open" error. The same issue appear if you want to work multi threaded.

This is a major issue when using static, and it is usually the reason for ruling them out. By the way, I'm using static as the word here, but everything I say here can be said about Singleton as well.

I'll post later how to handle this issue safely on multi threaded (and web) scenarios while maintianing the ease of use that static gives us.

 

time to read 1 min | 82 words

This is just to vent a personal frustration. There is nothing really new or innovative here.

Recently I've been spending a lot of time talking about a specific feature about how it should be implement and what the concerns should be and how it should be handled, etc. The sad part is that I could have implemented the feature and get working code in about one third of the time that it took to discuss the issues.m

time to read 10 min | 1928 words

Dave Peck has a post about the performance of Linq over collections, where he makes the comment:

static field access on generic classes is up to 100x more expensive than on regular classes.

I never even heard on this issue, so I decided to make a check, here is my test harness:

static void Main(string[] args)

{

       Normal current = new Normal();

       string temp;

       DateTime start = DateTime.Now;

       for (int i = 0; i < 1000000; i++)

       {

              temp = Normal.Static + i;

       }

       TimeSpan span = DateTime.Now - start;

       Console.WriteLine(span.Milliseconds);

}

Laughably simple, but it should give a fair idea about the issues. BTW, I'm using the string concatation as a way to prevent the compiler from optimizing the access. I would guess that this affect negatively on the result, but I'm not concerned about accuracy, I want to know the general amount of difference.

Here are the classes that I tested:

public class Normal

{

       public static string Static = "static-string";

       public string Instance = "instance-string";

}

 

public class Generic<T>

{

       public static T Static;

       public T Instance;

}

 

public class Generic2<T>

{

       public static string Static = "generic2-static-string";

       public string Instance = "generic2-instance-string";

       public T something;

}

The results are below. I would just like to note that this represent a couple of runs only, and I have seen the numbers jump around in about 100-50 ms difference.

  • Normal Static: 625ms.
  • Normal Instance: 609ms.
  • Generic Static: 578ms.
  • Generic Instance: 609ms.
  • Generic2 Static: 593ms.
  • Generic2 Instance: 578ms.

Base on this inclunclosive result, I don't think that there is any significant difference with regard to performance in access static or instnace field on generic class (or normal ones). In the tests above, all the results were fairly consistenly in the same range.

time to read 10 min | 1801 words

According to my code, it doesn't.

Here is the scenario, the scenario is supporting on the fly view updates for Brail. Recent changes in MonoRail meant that loading the view is now the responsability of the framework, and not the responsability of the view engine. This, however, presented a problem. Brail's view are compiled classes, but I want to allow edit & refresh cycles, so I can't force the develop to restart the application every time a view change.

So far, I handled it with a FileSystemWatcher that took care of it, but when the responsability moved to the framework, I needed to put something there that will give me the same functionality. The issue is that Brail is not the only View Engine for MonoRail (there are four that I am aware of), and Brail is the only one that needs this functionality. I should mention that FileSystemWatcher is a system resource, and as such, should be treated with care.

The solution, when it came to me, was relatively simple. Lazy events. Here is the code, which explain things better:

/// <summary>

/// Raised when the view is changed.

/// </summary>

public event FileSystemEventHandler ViewChanged

{

    add

    {

        //avoid concurrency problems with creating/removing the watcher

        //in two threads in parallel. Unlikely, but better to be safe.

        lock(this)

        {

            //create the watcher if it doesn't exists

            if (viewFolderWatcher == null)

                InitViewFolderWatch();

            ViewChangedImpl += value;

        }

    }

    remove

    {

        //avoid concurrency problems with creating/removing the watcher

        //in two threads in parallel. Unlikely, but better to be safe.

        lock(this)

        {

            ViewChangedImpl -= value;

            if (ViewChangedImpl == null)//no more subscribers.

            {

                DisposeViewFolderWatch();

            }

        }

    }

}

As you can see, there is a backend event that is doing the "real" work of handling subscribers and raising the event itself. What this gives me is to pay only for what I use. In this case, Brail needs this service, so it subscribe to the event, which causes the FileSystemWatcher to start working. When all the event subscribers are gone, the FileSystemWatcher is disposed.

This way, it make it look like it is continously watching, but it doesn't bother to do its work if there is no one who can't catch it sleeping on the watch :-)

time to read 2 min | 328 words

After reading the documentation, I have some unanswered questions about Linq For Entities, Microsoft new OR/M framework and I'm concerned about its usability in real life.

More spesifically, I'm concerened about the following:

  • Many to many relations. I have not seen a single mention of them in the documentation, and I know that DLinq doesn't support them.
  • Support for indexed collections (IList<T>) and maps (IDictionary<TKey,TVal>). Again, no mention of those in the documentation, and again, I'm pretty sure (but not completely) that DLinq doesn't support it.
  • Support for custom collections. I'm currently working on a project where just about everything is bound in time. This mean that the collection has to be aware of this. I don't see how I can achieve the same goal using Linq for Entities*.
  • How can I add a new type to the system? I have a column that in the model is boolean, but in the DB is null/not null (don't ask). How do I make map this?

To be presice, I want to know what the extention model is. There is no way that Linq for Entities can cover all the scenarios, and I have a wildly different experiances from Microsoft with regard to extention possibilities. Hell, just yesterday I learned that they decide that batching is too scary to let me handle it unless I'm going through data adapters. And I won't mention the pain that working with ASP.Net Cache is.

The really sad part is that they likely won't make those classes public ever, since they would consider this a breaking change.

*Someone please find a abbrevation for this monster.

time to read 12 min | 2324 words

I'm currently reading the documentation for ADO.Net Entities Framework. As always, I'm using this as a scratch pad for what I think as I read this.

Next-Generation Data Access - June 2006:

  • They still allow access to lower level services with the Entity Framework. Lower level is apperantely IDbConnection and IDbCommand. They mention the 80% brick wall, which is encouraging. The problem is that I don't like this solution. The framework should be flexible enough that I could plug in at all the important points and replace the functionality with my custom one. Using two ways to acess the data has a big "Don't Do Unless You Know What You Are Doing And Have Fasted For Three Days" sign over it with red blnking lights.
  • Chapter 3 is slightly interesting, 1,2,4,5 are extremely boring. Going over unrelated details (such as SQL Server ACID guarantees, merge replication, or order entry from 20 years ago). I understand the concept of a problem statement, but this is taking it to a new level.
  • Chapter 6 is about what they are trying to achieve. Admirable goals.
  • Chapter 7 shows the XML mapping. I'm not a fan of XML, and that XML is defiantely not something that you would want to write by hand.
  • One nice feature that I noticed is the ability to map several tables into a single entity. This has some performance implications, because of joins
  • I don't like that immediately show how to escape from the framework and go back to working with SQL and untyped data.
  • They mention WCFClient which sounds interesting. I'm not sure how that will work, the models are very different.
  • From the document, it seems like SQL Everywhere is going to ship with this, and be the local cache for the framework.
  • The MapProvider looks like it is the equilent of the ADO.Net driver. You apperantly get one for each DB provider. It looks like it provide quite a bit more, though. Mapping, eSQL (Entities SQL), etc.

Okay, that was the high level overview, let start on the real details.

The ADO.NET Entity Framework Overview June 2006:

  • Oh joy! Three ORM frameworks. Linq to SQL, Linq to DataSet, Linq to Entities.
  • I understand the need of simple examples, but this is wrong:
    where order.Status == "Pending Stock Verification"
    This is no data mdoel that I know. There is no need to start the bad habits in the documentation
  • This is a new record. They managed to piss me off on the very first page. The code example that they give as the desired state doesn't even make sense. Check the seond part of the example (in page 6), they load all the products, regardless of the order that has it. No order will ever ship unless all the products are shippable.
  • What about custom collections? I'm only 1/3 of the way, so it may appear later, but this is a very big concern.
  • Page 10: What do they mean? No behavior inheritance? If you map a table to a set of related classes, you bet you will get behavior inheritance. It is one of the more powerful features on an OR/M.
  • Sigh. It looks like this is much about providing a mapping layer between the database and the logical model, and getting uptyped results back. I'm not excited about this at all. This is where they are putting quite a bit of emphasis.
  • Given that they create a new langauge to work with the data, why not make it compatible with the way Linq work and use from-select-where ?
  • Check this:

    SELECT VALUE sp

    FROM AdventureWorks.AdventureWorksDB.SalesPeople AS sp

    WHERE EXISTS(

      SELECT VALUE o

      FROM NAVIGATE(p, AdventureWorks.SalesPerson_Order) AS o

      WHERE o.TotalDue > 200000)

    This query makes no sense to me at all, it is supposed to bring all the sales persons with a sale over 200,000. Is there a reason I need to know the foriegn keys between the two objects?
    The same query, expressed in HQL (Hiberante Query Languague) will look like this:

    SELECT sp FROM 

    SalesPeople sp join sp.Orders o where o.TotalDue > 200000
    Update 20:36: Fixed HQL Query.
  •  This is the magic? Please tell that they are joking...
    ctx.GetQuery<SalesPerson>("some eSql Query");
    p.Orders.Source.Where("it.Status == 0")
    Where is the Linq stuff? It was mentioned briefly as the ideal, but I didn't see it since (page 20).
  • A side note, I see a lot of code written like this:

    "SELECT VALUE "

    +
    "FROM AdventureWorks.AdventureWorksDB.SalesOrders AS o " +
    "WHERE o.Status = 0"
    C# has a multi line string. It bothers me to see that they are not using it.
  • Okay, chapter 4 is titled "Linq to Entities", so I guess there is Linq magic there.
  •  The Linq samples looks like I expected them too. So I guess that I worried for no reason.
  • The Linq on DataSet stuff it just ugly on untyped datasets. The difference between untyped & typed is just amazing.
  •  No word on the difference between Linq for SQL (DLinq) and Linq for Entities except that the mapping is done directly against the database and not against a mapping layer on top of the databse (oh, how the Architects are going to love this).
  • It looks like that are two types of mapping: Database --> EDM, Database?/EDM? --> Classes. And yet I see no references to the database on the EDM, and plenty of references to the database in the classes mapping.

Overall, not really impressed. I guess I will have to wait until I have the real bits to play bit, but except from the Linq magic, I don't see anything really interesting. I do foresee quite a bit of confusion, though.

FUTURE POSTS

  1. fsync()-ing a directory on Linux (and not Windows) - one day from now

There are posts all the way to Jun 09, 2025

RECENT SERIES

  1. Webinar (7):
    05 Jun 2025 - Think inside the database
  2. Recording (16):
    29 May 2025 - RavenDB's Upcoming Optimizations Deep Dive
  3. RavenDB News (2):
    02 May 2025 - May 2025
  4. Production Postmortem (52):
    07 Apr 2025 - The race condition in the interlock
  5. RavenDB (13):
    02 Apr 2025 - .NET Aspire integration
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}