Perhaps you should think about usage of EF in your application. EF's context should be used for as shortest period of time as possible:
- Create context
- Load data
- Modify data
- Save data
- Drop context
Because of internal implementation (IdentityMap, UnitOfWork) long living context is not a good choice and with short living context you don't want mentioned behavior at all. Even in desktop application you should use approach like context per form. You load data, you present data to your user and till that time only user can modify data and push save button - it is application responsibility to deal with concurrency issues somehow (timestamp). Automatic modification of data which are part of running unit of work is pretty bad idea - what if user already modified data? Will you overwrite his changes?
Edit:
You can read more about impelementation of ObjectContext
here.
I can imagine scenarios where data update notification to client applications are needed. It can be read-only real time data displaying - for example stock trading information. But in such case you need something more powerful. It is not scenario for client calling ORM to get data but the scenario for client subscribing to some service / middle tier which handles data retrieval and fast change notification.
For simple scenarios where you only need to refresh data in semi-real time fashion you can use polling - your client will call the query again within few seconds and use StoreWins strategy. Any notification strategy is outside scope of EF - you have to implement it as trigger, sql dependency, publish subscribe pattern or something else. Even with notification you will only be able to handle some event and requery the data.
Again if you want to reduce data transfer with polling you need some service / middle tier which will allow some level of caching (you can also try WCF Data Services).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…