Hi,
On 11.03.2010 12:25, Angela Schreiber wrote: > hi felix > >> Consier a UserManager not set to autosave mode. I do: >> >> Group g = userManager.createGroup(groupPrincipal) >> g.addMemmber(someUser); >> This results in an InvalidItemStateException: >> >> javax.jcr.InvalidItemStateException: >> c0a1a731-9fea-34fa-aa78-d224bd58a981 has been modified externally >> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1145) >> at >> org.apache.jackrabbit.core.security.user.UserManagerImpl.setProtectedProperty(UserManagerImpl.java:581) >> >> at >> org.apache.jackrabbit.core.security.user.GroupImpl.addMember(GroupImpl.java:151) >> >> >> I assume this is because the addMember method calls Item.save() while >> the parent node has not been saved yet. The cause, as it turns out, is another thread modifying the group at the same time as my code tries to add the member to the group. This modification is part of our in-house application based on Jackrabbit. This is not directly related to Jackrabbit (at the moment), though IMHO Jackrabbit should probably be more lenient here ... > > but why is the save method called? if you are *not* in > autosave-mode the save-call should be omitted and you are > in charge of calling session.save to persist the complete > set of transient modifications anyway... strange. Well, apparently the UserManager *is* in auto-save mode, since I did not change it. So it is out of my control whether the addMember calls save or not. > >> Is this a known issue worth following up to ? > > no, this isn't a known issue... can you check why > Item.save() is called in the first place? and file > a new JIRA issue if it's a bug in the user-management code. As said above, the problem is probably not the user-management code itself but something else. So, sorry for the noise. Regards Felix
