Understanding the Manipulation of the Relationship

[Alibabra Sanjie]

In Spec,

Bean Provider MUST NOT modify the container-managed COLLECTION while the iteration is in progress in any way that causes elements to be added or removed, other than by the java.util.Iterator.remove() method. If elements are added or removed from the underlying container-managed collection used by an iterator other than by the java.util.Iterator.remove() method, the container should throw the java.lang.IllegalStateException on the next operation on the iterator.

I don't really understand this sentance. Can someone explain why is like that?
Example:
Collection nySalesreps = nyOffice.getSalesreps();
Collection sfSalesreps = sfOffice.getSalesreps();
Iterator i = nySalesreps.iterator();
Salesrep salesrep;
// a WRONG way to transfer the salesrep
while (i.hasNext()) {
salesrep = (Salesrep)i.next();
sfSalesreps.add(salesrep); // removes salesrep from nyOffice
}
Why is wrong? Why Adding the salesrep will cause the salesrep removes from nyOffice?

[Constantino Cronemberger]

Your example is not always wrong. It depends on the multiplicity of the relationship. In this case the options are one Office to many Salesrep or many Offices to many Salesrep (one-to-many or many-to-many).
If it is many-to-many there is no problem with this example, because the add act as a copy operation, not a move.
If it is one-to-many it is indeed wrong, because in doing that you are removing the iterator's current element from the collection and it will invalidate the iterator. What would be the current element after such a removal?
An alternative and cleaner way of doing this transfer would be:
sfSalesreps.addAll(nySalesreps);

[Alibabra Sanjie]

But why Adding the salesrep will cause the salesrep removes from nyOffice? How that could be done since I didn't see and code for removing the salesrep from nyOffice. I only see adding.

[Constantino Cronemberger]

Have a look at section 10.3.6 of the spec.
When you add the salesrep to sfOffice it gets removed from nyOffice because the relationship is one-to-many, and that means that a given salesrep can be in a relationship with only one office. So if you add it to nyOffice it has to be removed from sfOffice otherwise the multiplicity restriction would be broken.

[Ramakrishna Allam]

Infcat what he says on the page 135 of the spec is ,

If elements are added or removed from the underlying
container-managed collection used by an iterator other than by the java.util.Iterator.remove() method, the container should throw the
java.lang.IllegalStateException on the next operation on the iterator
Collection nySalesreps = nyOffice.getSalesreps();
Collection sfSalesreps = sfOffice.getSalesreps();
Iterator i = nySalesreps.iterator();
Salesrep salesrep;
// a wrong way to transfer the salesrep
while (i.hasNext()) {
salesrep = (Salesrep)i.next();
sfSalesreps.add(salesrep); // removes salesrep from nyOffice
}
// this is a correct and safe way to transfer the salesrep
while (i.hasNext()) {
salesrep = (Salesrep)i.next();
i.remove();
sfSalesreps.add(salesrep);
}

The first comment is beacuse of the referential integrity . But doing that way , will throw an IllegalStateException . We should do the second way .

[Alibabra Sanjie]

So, in general when we add, we have to remove first due to the referencial integity rule, and we have to have a specific code for removal, it is not done automatically, right?!

[Ramakrishna Allam]

You are right . U need to have a specific code to remove it through Iterator.remove() . otherwis e, u will see a IllegalStateException

[Ramakrishna Allam]

instead of using collections and adding it specifically , if u use set methods of the bean , no need to remove them specifically . Container takes care of it.

[Alibabra Sanjie]

Can I always use set methods for the relationship manipulation, and let the container take care of the rest? If that is the case, the code for the relationship will be much simplier and easier!