updating CMR field with Many-to-Many relationship

[Milan Unger <mi...@siemens.com>]

Hi,

I'm experimenting with geronimo 1.0-M5. I have to update CMR field
(Many-to-many) to re-assign new user list to  the unit  entity

    // UnitManagerBean session bean:

    public void updateUnitUsers (Integer aUnitKey, Collection userLogins)
    throws NamingException, FinderException
    {       

        UserLocalHome aHome = lookupUserBean ();                       
        Collection<UserLocal> users = new Vector<UserLocal> ();
        for (String aLogin: (Collection<String>)userLogins)
        {
            UserLocal aUser = aHome.findByLogin (aLogin);
            users.add (aUser);           
        }
        UnitLocal aUnit = lookupUnitBean ().findByPrimaryKey (aUnitKey); 
        aUnit.setUsers (users);
    }

UserLocal and UnitLocal are CMP Entity beans. I collected all UserLocal
entities into Vector and assigned it to UnitLocal instance via
setUsers() (CMR field). Anyway, current implementation seems to work in
the way that if the given Group entity was in the list previously it is
removed, but not added. For example, if the UnitLocal.getUsers() returns
list ('user1'), and I used UnitLocal.setUsers() with list
('user1','user2') the result returned from UnitLocal.getUsers() in next
transaction is ('user2'). Similary, if list ('user1', 'user2') is
updated with the same list ('user1', 'user2'), the result is empty list.

Only solution I have found how to resolve this is to clear the list with
empty list in first transaction, and then to set it to desired list in
the second transaction:

        // web client calling UnitManagerBean
        List<String> logins = getSelectedUsers ();       
        lookupUnitManager ().clearUnitUsers (itsUnitKey); //this needs
to be called to clear user list before setting it to new list
        lookupUnitManager ().updateUnitUsers (itsUnitKey,logins);

I tried also different methods to update the CMR field (e.g. calling
getUsers instead of creating Vector and updating it directly) but the
result was always the same.

I can live with that solution, but anyway: is this the expected behavior
or a bug? Is there some way to get desired behavior in a single transaction?

Regards, Milan.