Michael A. Rose wrote:
Essentially, should each business object simply create a new ObjectContext, or should a common ObjectContext be passed around? And if so, what is the proper lifecycle? Application, Session or Request?
Do not use a global ObjectContext at the application level since all domain objects it stores can be concurrently accessed by different threads, it is better to store only infrequently modified data within application scope. The ObjectContext is not thread-safe. It was never meant to be. Therefore, it is a bad idea to access it from several threads at the same time.
Per-session or, sometimes, per-request is the preferred way of using ObjectContext in a web application. An application wide cache should be implemented as an IDataStore that sits 'between' the ObjectContexts and the (database) data store.
1 Comment
Hide/Show CommentsMay 16, 2007
Ulu Honolulu
I've been using the Context as a static variable for some time now, and it works pretty good for low-traffic sites. The only thing you should modify is make read-write operations thread safe by making a lock on the Connection object. You should also remember to either save or cancel all your changes on the same page you made them, or other users will see the unsaved changes (which is bad if you use autoincremented keys). So, if your app is not mission-critical, I'd say go for it.