What exactly is the difference between the three commit modes?

The easiest to understand is Option C, which, as you can see in the diagrams in the specification, causes an entity bean to be passivated and activated between transactions. A scenario is as follows:

  1. Your entity bean is marked as transaction “Required”. If the client is not running a transaction, the Container starts one around every client call into the bean. So, when the client calls "create", a transaction is begun.
  2. When the creation is complete (for example, after ejbPostCreate) the transaction is committed.
  3. With Option C, after the transaction is committed, the entity bean is passivated.
  4. The entity bean is activated for the next transaction and passivated when it completes.

If you want to play with this, try creating a user transaction, that spans both the create and a business method: 
        userTx.begin();
        Entity entity = entityHome.create();
        entity.doWork();
        userTx.commit();
You will notice the entity transition from "pooled" to "ready" state via an ejbCreate and then get passivated. On the doWork() call it will get activated and passivated again.

In Option B, the container will not call passivate after a transaction and subsequently will not call activate before the next transaction using the same entity bean. The ejbStore still happens on a commit.

In Option A, the container assumes it has exclusive access to the database and does not need to load the entity bean during the next transaction using the same entity. When the database is unshared, it is possible to avoid reading the state of an entity bean at the beginning of a transaction by using the state of the entity bean from the last (committed) transaction.