Although i havent read those notes but Here is the deal ..
When you call ejbRemove()? do you have any idea what to remove? As in which Entity?
So, Here is what you do?
Activate a bean instance from the pool...in your ejbLoad() ..use the context to get your primary key...load this bean using this primary key..now you are all set to remove..arent you?
The implementation may differ..but logic remains the same
To your next Question... Try thinking on these lines..
1) When would i usually need a Transaction? Answer) Normally when i use a business method for reading data from the database?
2) Why then? Answer) Because with a proper locking level during the Transaction..i would ensure that when my EJB operates on the data..no one else can..
Now, back to your Question
Typically you would call an ejbSelect()..through a home business method or to select data straight from the bean(not exposed to client). For this you should do it in Transaction...
Unlike others ejbRemove() of an entity bean runs in a Transaction..one of the reasons being..that you dont want any other access to the data while you are removing it
Now, coming to the fact that why do they the context of Transaction that invoked them...
When you invoke a business method on an EJB Object...and the particular entity bean instanceis unavailable..it will call ejbActivate()..now thats too early for a transaction..then container calls ejbLoad()..where you load database data...apt place to begin transaction and lock database row(may be)..Rest explanation..read the top part again