Thursday, July 2, 2015
Tuesday, January 8, 2013
Firstly, some basic configuration details. Below is my basic configuration for log4net.
Now, as far as I am aware there is nothing specifically wrong about this configuration. It does indeed log to both a database and also a text file. However, under load some curious things happen. First of all, you can get an I/O race condition appearing regularly in the logs. This is because the load can cause 2 threads to want to write to the text file at the same time, causing the I/O race condition to occur. To fix this, remove the text file log appender updating the root node as below:
So, what caused the issue? From what I can tell if you have a ADO appender as in the example above, you can't just turn off logging. From what I have experienced this will still connect to the database AND WONT RELEASE THE CONNECTION TIL THE CONNECTION EXPIRES. And that is the key thing here. If your database connections time out after 2 minutes, you can see how the connection pool can get clogged with these open logging connections that do nothing. What you need to do is remove or comment out the ADO appender from the list of appenders as below:
If you want to use the above to configure to a database, below is the SQL that you need to create the table. Just make sure your connection string is correct and that the user that is running the website has access to the databse the table is in.
Friday, January 4, 2013
It has been a while since my last post, having been really busy at work getting some projects completed. However, as its the start of a new year, I'm thinking I should get back to blogging.
So, I'm going to start work on a new self learning project, like the Java OData and the SQL audit tools I wrote previously. While I'm not going to share what the project is, I will try share what I learn while doing the project. What's the point of working on a project? Well, I like having a purpose for doing something. I like to have a goal and try to meet that goal. Also, I am working on my project from the beginning, to see thoughts turn into requirements into functionality. But when it comes down to it, I just like a challenge.
Now the basic frameworks/languages/processes will be MVC 4, C#, Razor, agile, HTML5, CSS3, WCF and MS SQL 2012.
I already have some ideas for some future posts, so watch this space.
Tuesday, March 20, 2012
Here is the senario: you have nHibernate (in my case fluent nHibernate) and you have some collections (and properties) to be lazy loaded. You also have your entities mapped to a DTO entity for sending over the wire. Now, my problem was that the lazy loading was not working, when I monitored the SQL trace I could see every member and every collection being loaded regardless of what I had configured in nHibernate. This was causing around 400 SQL statements to be executed to the database, and I could not work out why.
Now, the answer seems simple now that I know what it is, but needless to say it took a few hrs to work out what the issue was, and then another few hrs to actually get a solution that I was happy with. But, I think I have a solution I can be happy, especially now that I have gotten the 400 or so SQL statements down to about 50 for the first load, and 5 (I am hoping I can get that down to 3) for every other load in the nHibernate session.
So, I hear you ask, what was causing this blow out? It was the AutoMapper checking the value of the entity that was triggering the lazy loading of the collections and properties, which then resulted in every member in the object being loaded, then every member in every child entity, and so on until the entire entity tree was being loaded. Now, I am sure that I might have a configuration setting not set up properly, or I might have something wrong with my entity definition, but from what I have found this is pretty standard behaviour.
Now for the fix. It is really neat, and is done in the AutoMapper configuration when you create your maps between your entity and DTO object. I had basic mappings set up (my DTO’s are closely aligned with my entities), so a sample mapping would be:
Now, that is fine, but to stop the Lazy loading being triggered I needed to add a bit to the mapping definition when mapping the entity to the DTO (I don’t care about the mapping from the DTO to the entity, no data access there). So my mapping from about became:
Mapper.CreateMap<Entity, EntityDto>() .ForMember(dest => dest.Collection, opt => opt.Conditional(dest => NHibernateUtil.IsInitalized(dest.Collection));
As you can see, this simple change is nice and neat, and stops the AutoMapper triggering the Lazy Loading of the entities. And, as we stop the lazy loading, we stop the extra unwanted and un-needed calls to the database.
Anyway, just thought I would mention it and hopefully help someone else having the same fun as I was. Let me know your thoughts.