Asynchronous & Concurrent Queries with a single Unit of Work

I've run into an issue using LightSpeed in a Rich Client application (WPF).

I am sharing a UnitOfWork for each View/ViewModel that I create. When I open the view, I want to go and grab the required data for each view. This would include the main entity I am working on, plus any related data (could be lists for combo box controls, etc). Now I am following best practices and doing this work on a background thread; however I would like to do these requests concurrently, rather than serialy.

If I attempt to load this data asychronously & concurrently, I get an exception (as the connection is already in use).

Now (and somewhat related), the lifetime of the UnitOfWork for each view is quite long (as long as the view is open, which could be minutes, hours, or days). After reading the help file, I notice that the default ConnectionStrategy keeps the database connection open for the life of the UnitOfWork. Thus, I began looking at the post here that describes creating a custom ConnectionStrategy. My thoughts are that I may be able to create a custom ConnectionStrategy that determines if the current connection is in use, and therefore will create a new connection for the operation. However, I am very worried that the UnitOfWork has not been designed for asynchronous "population" - and thus might run into threading issues.

Am I on the right track? Should I create a custom ConnectionStrategy that basically has a "pool" of connections that can be used as needed?

There is the potential for problems if two threads try to materialise the same entity at the same time.  Entity materialisation is not completely atomic: it is possible for one thread to look in the unit of work, go "Widget #234 isn't loaded yet," start creating it, and while it's doing that another thread also looks in the same unit of work, also goes "Widget #234 isn't loaded yet" and starts creating a second entity.  Result, you end up with two versions of Widget #234, one of which has been displaced from the identity map and therefore won't get saved if you make changes.

If you're careful never to issue two concurrent queries which will load entities of the same type, then your approach sounds like it should work -- but it's not something we've tested so you may run into issues I haven't thought of here.  Obviously we'll be happy to provide support and advice though.

One thing to watch out for is association traversals.  For example, consider the following scenario: Widget has a property of type Sprocket.  You're loading Widgets in one thread to display in the WPF form, and Sprockets in another thread to populate the combo box.  The combo box SelectedValue is set to the Widget.Sprocket.Name.  So when the Widget displays, WPF will access the Sprocket property, causing LightSpeed to load the relevant Sprocket.  If that happens to occur concurrently with the loading of the Sprockets for the ItemsSource, you could hit the problem described above.  A similar issue can occur if Widget.Sprocket is eager loaded.  So you will need to plan your loads quite carefully.