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
|
Thought I'd start a new thread as the other way has got a bit long. Thanks for the commandTimeout functionality - seems to be working fine. I have a question about how best to achieve what I'm doing. At the moment I have a Winform that is used to run some queries manually if the overnight batch that runs them on the server failed for any reason. These can take a couple of minutes. I have been using the same context as the rest of the app and just increasing the timeout property, then setting it back when done and running it within the DoWork event of a backgroundWorker. Whilst things are running there is a progress bar that spins to let them know something is going on. At the moment, this is fine and the users cannot navigate away from the form to do something else, they can just cancel the query. However, once I can educate the users a bit more *grin*, I want to let them fire off the query, then go an do other stuff whilst it's running (a couple of the queries could take up to 5 minutes). So, I thought I would create a new context to run the query so I can leave the main context timeout as is for other queries that may be made whilst the long query is going. Now, would it be better to use a PerThreadUnitOfWorkScope for this rather than the plain old UnitOfWork and if so, why ? I'm fairly new to all this threading malarky, so apologies if this is a bit of a basic question... |
|
|
|
|
It doesn't really make much difference because if you are using a different context you are going to get different unit of work objects anyway. Using a scope won't really add anything, and could cause issues if the user reruns the sproc while it's still chuntering away in the background (because the scope will return the same UOW, which means it will try to use the same connection, and the connection will be busy), so I'd just stick to plain old UnitOfWork. I'd also suggest that since you're "fairly new to all this threading malarky," you might want to defer making this decision until you decide to implement the "fire and forget" functionality, as this gives you a bit more time to get comfortable with the platform, with LightSpeed and with the joys of async programming. I don't think splitting out a dedicated context will be any harder to do at that point than it is now, so I don't think you're gaining anything by trying to anticipate the future design. Just a suggestion of course! |
|
|
|
|
Cheers Ivan. Yes, you are right, probably better to leave as is for the moment until someone complains ! |
|
|
|
