Because removing an entity from a collection is an ambiguistic action (it can mean different things), you have to tell the code what you want to do. This is done best with keeping track of what you want to do using a unitofwork object, or by keeping a different collection around in which you store the entities to delete.
This way you can then save the objects in one go at the end of the form, or simply throw away the tracked objects when the user clicks cancel (that's why it's important actions are done at the end!
)
It's up to you how you track this, there are various options available, like a unitofwork object or a dummy collection. Also use the option to save field values inside an entity if you want to roll back changes when the user clicks cancel.
The work you should do behind the form should be targeted towards building up the information to send to the persistence layer for processing. So adding an entity to another entities' collection will make them related to each other and as it is an existing entity, FK's will by synchronized. If you want to undo that situation later on, because the user clicked cancel, you have to undo that assignment as well, there is no rollback feature there (which would be nice, but is very complex to implement and use, that's why it's not there (yet))