public virtual MemoryStream

Object/Relational mapping tools sound wonderful in theory. You get a type-safe object-view to your database, there's no more need to do any kind of manual SQL coding, database changes typically only need changes in one place in your code-base, sometimes the O/R tool performs a certain level of caching for you, etc. etc.

Unfortunately in practice things aren't always quite that wonderful. The main problem is that, because you don't write the SQL yourself, you typically have very little control over the SQL that is used to communicate with your database. Some SQL may be impossible to generate - try to write a CMP finder for example that returns rows from more than one table/object, or try to update more than one record at a time. And for actions that are possible, there is oftentimes no guarantee as to how many SQL statements are executed to get the desired result. For instance, if you have a one-to-many relationship between COMPANY and ORDER, and you retrieve all COMPANY objects that adhere to certain criteria, and then get all their ORDERS, many O/R mapping tools will end up executing N+1 SQL queries: 1 to return the N COMPANY objects, and N more for their associated ORDER objects. This is a totally unscalable approach of course.

To make things worse, because this happens behind the scenes, you oftentimes don't even find out about it until you start working with large datasets and your system begins to slow down to a crawl. Once you get there, how do you know what code caused the sudden drop in performance? Running a profiler on your application is generally a good idea, but when using a O/R mapping tool, 9 out of 10 times the performance hit will have been caused by too much SQL and a good JDBC logger can be used to pinpoint the problem.

Now many JDBC drivers have an option to perform logging themselves. Unfortunately they oftentimes spit out way more information than you need and finding the repetitive SQL statements becomes like searching for a needle in a haystack.

I recommend instead using an open source tool called p6spy for this purpose. p6spy is JDBC logger that sits in between your application and the real JDBC driver. It intercepts all calls to the real JDBC driver this way and subsequently logs a single line per executed SQL statement. It is easy to install and highly configurable through a properties file - allowing the user to for instance only log certain actions, or log a stack trace along with every SQL statement log to easily trace the SQL back to the code that caused it.

Using a tool like p6spy it becomes possible to catch the N+1 problem even in small datasets where it hasn't yet become a performance problem. You can then try to tweak the O/R mapping tool settings or your interaction with the tool and hopefully change things or the better. I highly recommend it.