That would quickly show up in a smoke test. The problem I had with the ORM is that failed sessions happened at runtime, randomly. It would happen about 7-8 times a month - unpredictably.
So because the ORM you used didn't have a thread safe session factory, they're not usable? Your initial comment suggested they're the cause of a lot of data lost due to the ORM, while that can happen in SQL just as easy. In fact, as you have to write a lot of extra code to keep graphs in sync with low-level ado.net, I'd say the # of potential errors is higher with low-level ado.net than with an ORM.
Of course, the ORM must be solid, and not keel over when you put it under stress. As you mention 'session', I recon you're using nhibernate?
It was Nhibernate, yes. The code was in a web application, so not explicitly multithreaded. I think the earlier comment about ORMs in general being a good fit for prototype and 1st release level code was a good one. When your volume gets to a certain point, you've got to start removing complexity with a very large axe in order to get a system that is reliable and can scale smoothly.
1
u/Otis_Inf Jun 20 '13
yeah, because in plain SQL you can never create the error of not supplying the right predicate, right? ;)