Using commit option A or B leaves a cached bean instance in the container. This means that the following happens for me:
1. create "A"
2. remove "A"
3. create "A"
The result is a
javax.transaction.TransactionRolledbackException: INSERTING AN ALREADY EXISTING BEAN
Step 2 has removed the database record, but the bean from step 1 remains cached. This causes step 3 to fail.
This seems to match the spec/JBoss doco, but doesn't seem to make sense to my application. Why doesn't ejbRemove invalidate other bean instances, as logically the client should be able to view the data as a single entity?
Will only using option C fix this?
Looks like a bug. Please, post a small test case at SourceForge.