EJB: removing local TOs  
Author Message
Timo Nentwig





PostPosted: 2005-1-13 18:20:00 Top

java-programmer, EJB: removing local TOs Hi!

This applies to WebLogic 7 but probably is generally the case.

I have a Collection of Local objects which I want to remove(). So I thought
collection.clear() would be sufficient and the container would do the job.
But it doesn't.

So, I iterate thru the Collection and call remove() on each Local object.
This throws a ConcurrentModificationException because the container does
remove the element from the Collection when calling remove() on the Local
object.

The only solution seems to iterate over the collection, put the objects to
be deleted in another collection, iterating over that collection and
calling remove() there on any Local object.

Well, there must be something I misunderstood about EJB, right?

 
Collin VanDyck





PostPosted: 2005-1-13 22:06:00 Top

java-programmer >> EJB: removing local TOs Timo Nentwig wrote:
> Hi!
>
> This applies to WebLogic 7 but probably is generally the case.
>
> I have a Collection of Local objects which I want to remove(). So I thought
> collection.clear() would be sufficient and the container would do the job.
> But it doesn't.
>
> So, I iterate thru the Collection and call remove() on each Local object.
> This throws a ConcurrentModificationException because the container does
> remove the element from the Collection when calling remove() on the Local
> object.
>
> The only solution seems to iterate over the collection, put the objects to
> be deleted in another collection, iterating over that collection and
> calling remove() there on any Local object.
>
> Well, there must be something I misunderstood about EJB, right?
>

Try this and see what happens:

Collection localObjects = objectHome.findSomeToDelete();
for (Iterator objIter = localObjects.iterator(); objIter.hasNext();)
{
LocalObject obj = (LocalObject)objIter.next();
objIter.remove();
obj.remove();
}

 
John C. Bollinger





PostPosted: 2005-1-13 23:07:00 Top

java-programmer >> EJB: removing local TOs Timo Nentwig wrote:

> Hi!
>
> This applies to WebLogic 7 but probably is generally the case.
>
> I have a Collection of Local objects which I want to remove(). So I thought
> collection.clear() would be sufficient and the container would do the job.
> But it doesn't.
>
> So, I iterate thru the Collection and call remove() on each Local object.
> This throws a ConcurrentModificationException because the container does
> remove the element from the Collection when calling remove() on the Local
> object.
>
> The only solution seems to iterate over the collection, put the objects to
> be deleted in another collection, iterating over that collection and
> calling remove() there on any Local object.
>
> Well, there must be something I misunderstood about EJB, right?

It sounds like the Collection in question is the representation of one
of an entity bean's container-managed relationships. In that case, yes,
there is something you do not understand: modifying the collection
affects the _relationships_ defined for the entity from which you
obtained the collection, not (directly) the other entities themselves.
When you remove an entity from the collection in any way, you clear the
relationship without destroying the entity. If you remove() the entity
then the Collection is automatically updated because the source entity
cannot have a relationship with a non-existent entity. This all is
generally a good thing, but it does present a minor problem for the
scenario you describe.

You must either
1) clear each relationship while retaining a handle on the related
entity, then remove the entity, or
2) remove the entities without worrying explicitly about the relationships.

Your proposed solution is a variation on (2); if I did it this way,
however, I would not explicitly iterate over the Collection you already
have, but instead use

List toRemove = new ArrayList(entityCollection);

then iterate over toRemove and invoke remove() on each element.


Collin's suggested solution is a variation on (1).

Which is preferrable is a matter of taste and style; performance
probably is not a factor unless you have truly massive collections.


John Bollinger
email***@***.com