C#

class Emp : IEquatable<Emp>
{
   public string Empname { get; set; }
   public int ID { get; set; }

   #region IEquatable<Emp> Members

   public bool Equals(Emp other)
   {
      if (Object.ReferenceEquals(other, null)) return false;
      if (Object.ReferenceEquals(other, this)) return true;

      return ID == other.ID && 
                   Empname.Equals(other.Empname);
   }

   #endregion

   public override int GetHashCode()
   {
      //Calculate hash
      return Empname == null ? 0 : Empname.GetHashCode()^
                                   ID.GetHashCode();
   }
}

var u = list2.Intersect(list1);

FileStream fs = File.Open(filename, FileMode.Open, FileAccess.Read, FileShare.Read);

BobJanova wrote:

This will succeed where an attempt to open the file read/write won't if another application has done the same thing. However, most applications lock files completely while in use (and some, notably MS Office, keep the file locked while it is open ... bad practice, that), and there is simply no way to read such a file while the other application has it open.

BobJanova wrote:

There's no reason for a program like Word (or Adobe Reader, lest ye think I'm just being anti-Microsoft) to hold the file open the entire time you are looking at it

Bastard Programmer from Hell

BobJanova wrote:

The file should be locked against reading when it is actually being written. In a document editing app, that should be the time between pressing 'Save' and the save completing.

• For a reading repository:
  
  
  
  • Non volatile, i.e. they don't change very often. A cache that has to refresh every request is no use.
    
  • Large. You still have to check whether there's been a change (usually involves adding more to the data source and a small amount of overhead), so the cached data needs to be large enough that the request for 'has it changed' isn't as much effort as just getting the data would be. Note that this generally means that you can't cache at the single entity (i.e. one row) level, as finding out if a row changed is as heavy as just returning the row, unless the row is very large and bandwidth to the database is an issue. (If you don't care if your information is out of date, you don't need to ask the DB and you can ignore this. But usually you do care.)
    
  
  
• For a writable repository:
  
  
  
  • Not shared between processes, or not synchronisation-critical. There's no point having a write-back cache if you have to invalidate it immediately to synchronise the data with another process. However, if you are updating things frequently, and don't need every change to commit to the database immediately, you can save a lot of database updates.