Any changes made to the entity are not persisted until you call SaveChanges on the context. You can do changes in multiple entities and store them at once. This is called Unit of Work pattern. You can't selectively say which modified attached entity you want to save.
Combine these two patterns and you will see some interesting effects. You have only one instance of entity for the whole application. Any changes to the entity affect the whole application even if changes are not yet persisted (commited). In the most times this is not what you want.
You can always think about context as about Unit of work. Create context when you open Edit dialog, load data for editation, modify data, save changes, close context. In server scenario it depends on situation. Sometimes it is enough to have context in single method but if you want to make multiple operations working with data you can share the context among multiple methods. Again - unit of work. Things which should be handled together should use single context.
refs
http://stackoverflow.com/questions/3653009/entity-framework-and-connection-pooling/3653392#3653392
http://msdn.microsoft.com/en-us/magazine/ee335715.aspx