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
|
We are developing a CAD/CAE system using Lightspeed 4. Currently I'm trying to perform all SaveChanges on a separate thread/task in order to improve End User experience (no waiting time). I guess I can concurrently run SaveChanges and read from Lightspeed objects (derived from Entity) with no harm. The only case which makes me uncertain is the case when I try to read from the object which has not been read from the database yet - it must be downloaded and I'm afraid that concurrent reading/writing operation may corrupt internal Lightspeed entity map. That's why I'd like to lock the db reading operation before SaveChanges hasn't finished. Is there any possibility to get notified that DB read operation is about to start? In that notification I would wait for SaveChanges to complete. |
|
|
|
|
We do not test multithreaded access to a unit of work so we're not sure what sort of issues you might encounter -- for example a unit of work encapsulates an IDbConnection and sharing those between threads is a bit dicey. In recent nightly builds we have added an Interceptor.ExecuteCommand method which you can override to intercept all database queries (read or write). You could perform some sort of locking or throttling here. You could also check the ConnectionStrategy class and/or consider overriding UnitOfWork.SaveChanges(bool). Some combination of these would probably get you what you want. If your separation is strictly "all reads/object operations on one thread, all saves on another thread" then 'reading from an object which has not been read from the database yet' shouldn't be an issue. You would never see a partially loaded object because all database loads occur on the same thread as reading the object. If you have multiple read threads then you have a big problem with the identity map -- e.g. Thread A and Thread B both try to load Product #1, both see it is not in the identity map, Thread A materialises an entity and puts it in the identity map, then Thread B materialises another entity and puts that in the identity map, overwriting Thread A's entry. Now Thread A has an entity which it thinks is part of the UOW but it has actually been kicked out by Thread B's version. |
|
|
|
