LINQ to SQL and Data Context Awareness
If you have developed applications with LINQ to SQL, you know that one of the features of these objects are that they are aware of the DataContext they were created in. This can have issues in ASP.NET if you do not cache the DataContext it belonged to, because each LINQ to SQL business object knows which context it was created in, and if it isn't the current one, then an exception is thrown.
It's possible to create new business objects without them being known by the DataContext; when you first create an object, until that object is passed along to the DataContext through InsertOnSubmit, the data object can be a temporary holder of data disconnected from the database. It's also possible to create relationships for the data that are also disconnected from the database, so you can build a whole tree of relationships of objects rather easily, all in disconnected form.
If you like to use that approach, use caution. If you add one object as a reference to a disconnected object that is DataContext-aware, then all of the other disconnected objects related to that object will all be queued up for insertion, which is a HUGE pain. If you get a lot of duplicated data, this is the first place to look; is a DataContext-aware object reference being assigned anywhere? If so, remove it, and make a reference by key.
That can pose problems because one of the nice features of LINQ to SQL is being able to drill-down an object model using the PK/FK properties, but in disconnected mode, all of the data has to be disconnected, and reference data won't work because you aren't usually creating it on the fly. Creating temporary matching records isn't typically a good idea as well, because if they aren't removed, data will be duplicated, plus removing the objects later may damage the reference for the real value potentially.
So what are the options here? I'd recommend storing as little disconnected data as posslble, or make sure you tread lightly.