Search results matching tag 'Future'

NHibernate Futures

Ayende — Mon, 27 Apr 2009 05:33:00 GMT

One of the nicest new features in NHibernate 2.1 is the Future<T>() and FutureValue<T>() functions. They essentially function as a way to defer query execution to a later date, at which point NHibernate will have more information about what the application is supposed to do, and optimize for it accordingly. This build on an existing feature of NHibernate, Multi Queries, but does so in a way that is easy to use and almost seamless.

Let us take a look at the following piece of code:

using (var s = sf.OpenSession())
using (var tx = s.BeginTransaction())
{
	var blogs = s.CreateCriteria<Blog>()
		.SetMaxResults(30)
		.List<Blog>();
	var countOfBlogs = s.CreateCriteria<Blog>()
		.SetProjection(Projections.Count(Projections.Id()))
		.UniqueResult<int>();

	Console.WriteLine("Number of blogs: {0}", countOfBlogs);
	foreach (var blog in blogs)
	{
		Console.WriteLine(blog.Title);
	}

	tx.Commit();
}

This code would generate two queries to the database:

Two queries to the database is a expensive, we can see that it took us 114ms to get the data from the database. We can do better than that, let us tell NHibernate that it is free to do the optimization in any way that it likes, I have marked the changes in red:

using (var s = sf.OpenSession())
using (var tx = s.BeginTransaction())
{
	var blogs = s.CreateCriteria<Blog>()
		.SetMaxResults(30)
		.Future<Blog>();
	var countOfBlogs = s.CreateCriteria<Blog>()
		.SetProjection(Projections.Count(Projections.Id()))
		.FutureValue<int>();

	Console.WriteLine("Number of blogs: {0}", countOfBlogs.Value);
	foreach (var blog in blogs)
	{
		Console.WriteLine(blog.Title);
	}

	tx.Commit();
}

Now, we seem a different result:

Instead of going to the database twice, we only go once, with both queries at once. The speed difference is quite dramatic, 80 ms instead of 114 ms, so we saved about 30% of the total data access time and a total of 34 ms.

To make things even more interesting, it gets better the more queries that you use. Let us take the following scenario. We want to show the front page of a blogging site, which should have:

A grid that allow us to page through the blogs.
Most recent posts.
All categories
All tags
Total number of comments
Total number of posts

For right now, we will ignore caching, and just look at the queries that we need to handle. I think that you can agree that this is not an unreasonable amount of data items to want to show on the main page. For that matter, just look at this page, and you can probably see as much data items or more.

Here is the code using the Future options:

using (var s = sf.OpenSession())
using (var tx = s.BeginTransaction())
{
	var blogs = s.CreateCriteria<Blog>()
		.SetMaxResults(30)
		.Future<Blog>();

	var posts = s.CreateCriteria<Post>()
		.AddOrder(Order.Desc("PostedAt"))
		.SetMaxResults(10)
		.Future<Post>();

	var tags = s.CreateCriteria<Tag>()
		.AddOrder(Order.Asc("Name"))
		.Future<Tag>();

	var countOfPosts = s.CreateCriteria<Post>()
		.SetProjection(Projections.Count(Projections.Id()))
		.FutureValue<int>();

	var countOfBlogs = s.CreateCriteria<Blog>()
		.SetProjection(Projections.Count(Projections.Id()))
		.FutureValue<int>();

	var countOfComments = s.CreateCriteria<Comment>()
		.SetProjection(Projections.Count(Projections.Id()))
		.FutureValue<int>();

	Console.WriteLine("Number of blogs: {0}", countOfBlogs.Value);

	Console.WriteLine("Listing of blogs");
	foreach (var blog in blogs)
	{
		Console.WriteLine(blog.Title);
	}

	Console.WriteLine("Number of posts: {0}", countOfPosts.Value);
	Console.WriteLine("Number of comments: {0}", countOfComments.Value);
	Console.WriteLine("Recent posts");
	foreach (var post in posts)
	{
		Console.WriteLine(post.Title);
	}

	Console.WriteLine("All tags");
	foreach (var tag in tags)
	{
		Console.WriteLine(tag.Name);
	}

	tx.Commit();
}

This generates the following:

And the actual SQL that is sent to the database is:

SELECT top 30 this_.Id             as Id5_0_,
              this_.Title          as Title5_0_,
              this_.Subtitle       as Subtitle5_0_,
              this_.AllowsComments as AllowsCo4_5_0_,
              this_.CreatedAt      as CreatedAt5_0_
FROM   Blogs this_
SELECT   top 10 this_.Id       as Id7_0_,
                this_.Title    as Title7_0_,
                this_.Text     as Text7_0_,
                this_.PostedAt as PostedAt7_0_,
                this_.BlogId   as BlogId7_0_,
                this_.UserId   as UserId7_0_
FROM     Posts this_
ORDER BY this_.PostedAt desc
SELECT   this_.Id       as Id4_0_,
         this_.Name     as Name4_0_,
         this_.ItemId   as ItemId4_0_,
         this_.ItemType as ItemType4_0_
FROM     Tags this_
ORDER BY this_.Name asc
SELECT count(this_.Id) as y0_
FROM   Posts this_
SELECT count(this_.Id) as y0_
FROM   Blogs this_
SELECT count(this_.Id) as y0_
FROM   Comments this_

That is great, but what would happen if we would use List and UniqueResult instead of Future and FutureValue?

I’ll not show the code, since I think it is pretty obvious how it will look like, but this is the result:

Now it takes 348ms to execute vs. 259ms using the Future pattern.

It is still in the 25% – 30% speed increase, but take note about the difference in time. Before, we saved 34 ms. Now, we saved 89 ms.

Those are pretty significant numbers, and those are against a very small database that I am running locally, against a database that is on another machine, the results would have been even more dramatic.

Future<T> Queries with HQL and Criteria

darioquintana — Fri, 30 Jan 2009 16:10:00 GMT

A few days ago Oren Eini and Davy Brion were working in a new feature for NH 2.1 (no a release yet) called Future, in the ICriteria API. You can see and explanation of the job here. Now I’ve committed a complement to enable that use into the IQuery API, for those who prefer to use HQL.

What is Future Query anyway? Future are queries that are kept, waiting to be executed as a group in just one roundtrip, making use of an underlying NHibernate feature: MultiCriteria/MultiQuery.

Let’s have a look to this simple piece of code. You can see both queries sentences, and both are executed in that sentence point against the database producing 2 roundtrips to the database. Nothing weird about this, but what if we can just execute the queries in just one roundtrip?

And now, using Future we can hold the execution, in this case just two, but we can hold how many queries we need.

Where is the trick? Future method is returning a delayed enumerable implementation, that’s all. When you iterate the enumerable (with a foreach for example), it detects and execute all the queries using a NHibernate-MultiQuery command (could be a MultiCriteria, it depends what we are using). But we don’t need to know nothing about the underlying implementation, just the concept.

In other terms, this is what happens behind the scenes:

But what if we want to retrieve an entity or a scalar ? This is too simple for an IEnumerable. Thanks to Davy Brion we have another feature called FutureValue. The mechanism is the same as Future, but instead of expect a IEnumerable, we obtain a single value (an entity or a scalar).

Note: examples adapted from Davy Brion posts [1] and [2].

NHibernate and Future Queries

DavyBrion — Sun, 25 Jan 2009 12:08:00 GMT

As some of you already know, i'm a big fan of avoiding excessive roundtrips by batching queries and/or service calls. For NHibernate, i wrote the QueryBatcher class which makes this pretty easy to do. Ayende recently added a much easier approach for this to NHibernate.

Take a look at the following code:

using (ISession session = sessionFactory.OpenSession())

{

// this executes the first query

var categories = session.CreateCriteria(typeof(ProductCategory)).List();

// this executes the second query

var suppliers = session.CreateCriteria(typeof(Supplier)).List();

foreach (var category in categories)

{

// do something

}

foreach (var supplier in suppliers)

{

// do something

}

This is a really trivial example, but it should be more than sufficient. It simply executes two very simple queries and loops through the results to do something with each returned entity. The problem, obviously, is that this hits the database twice while there really is no good reason for doing so.

With the new Future feature we can rewrite that code like this:

using (ISession session = sessionFactory.OpenSession())

{

// this creates the first query

var categories = session.CreateCriteria(typeof(ProductCategory)).Future<ProductCategory>();

// this creates the second query

var suppliers = session.CreateCriteria(typeof(Supplier)).Future<Supplier>();

// this causes both queries to be sent in ONE roundtrip

foreach (var category in categories)

{

// do something

}

// this doesn't do anything because the suppliers have already been loaded

foreach (var supplier in suppliers)

{

// do something

}

Apart from the comments, did you spot the difference? Instead of calling ICriteria's List method (which causes the query to be executed immediately), we call ICriteria's Future method. This returns an IEnumerable of the type you provided to the Future method. And this is where it gets interesting. Instead of executing the queries immediately, the queries are added to an instance of NHibernate's already existing MultiCriteria class. Only once you enumerate through one of the retrieved IEnumerables will all the (queued) Future queries be executed, in a single roundtrip. Once they are executed, their result is final (as in: enumerating through the IEnumerable will not cause the query to be executed again).

The example used here is obviously very trivial, but you can use this with any ICriteria so you can very easily start batching your complex queries as well. The kind of query doesn't really matter, as long as it's an ICriteria instance.

This feature will be available in NHibernate 2.1, or if you're using the trunk you can use it starting with revision 3999.