This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, let's say you had an entity called "User" and User has a property called "Order" which is a lazy loaded entity. When you call unitOfWork.FindOne<User>(4), the "User" object that you get back has a unitOfWork associated with it.
However, if you dispose of the unit of work, then call User.Order, you'll get an object already disposed exception message.
Is there some way to override how the User object finds a unitOfWork? So instead I could somehow tell it to get a new unitOfWork from a factory that I provide any time it needs to resolve a lazy-loaded entity? Thanks |
|
|
|
|
No, this is not possible, because LightSpeed expects all of the entities involved in a logical operation to be part of the same unit of work: it doesn't like having an association from, say, a User in UOW 1 to an Order in UOW 2. It makes this assumption because saving changes is a UOW-level operation: having entities spread across multiple UOWs would make saving changes a lot more difficult. What you'll need to do is instead either keep the UOW alive a little longer -- long enough for the Order objects to load -- or perform a new query through a new UOW. Which is appropriate depends on your environment e.g. if the lazy loading is a problem because of data binding in ASP.NET then the first approach is the better one, if it's a master-detail rich client then the second approach may be the way to go. We'd be happy to provide further guidance if you have a specific scenario in mind. |
|
|
|
|
This is for a WPF application.
If I had one UnitOfWork per thread, and did not dispose of them for the entire life of the application (and only dispose of it when the application is closing), would this cause any problems? Would I run out of connections to the database if many other people are using copies of the same program? Would the connections to the database potentially time out this way, or will LightSpeed automatically reopen the connection if it is closed? |
|
|
|
|
There are two potential problems there: 1. The unit of work maintains an identity map, so that if the same entity is retrieved a second time it can return the same instance. However, this means that entity data is not updated. So if other users make changes after an entity is loaded, you won't be able to get at those changes without creating a new unit of work. 2. By default, a unit of work is bound to a physical connection. So if there are lots of instances, you could starve the database of connections. In addition, if an error occurs on a connection, the corresponding unit of work won't be able to load or save entities any more. The second issue can be worked around by implementing a custom connection strategy. See http://www.mindscape.co.nz/blog/index.php/2009/10/26/database-connection-strategies-in-lightspeed-3/ and the linked forum post (although the article mentions LightSpeed 3, it works in the 2.2 nightly builds as well). In general however what we'd recommend is reviewing your load and save boundaries and keeping short-lived units of work. You can use the Attach method to move previously loaded entities into new units of work, or do it the Web way and just reload entities when entering new screens etc. JD has an article discussing the rich client environment at http://www.mindscape.co.nz/blog/index.php/2009/08/19/tips-for-rich-client-development/ which may give you some ideas. |
|
|
|
