IEntityGroup. Groups do not keep references to their members but instead cache member keys. The members are cached externally. The rules for controlling access to the key caches are a bit obscure, but you should understand them before writing code that updates groups. Access to the caches themselves is synchronized via the cache getters and setters. All requests to get group members and to add or remove group members ultimately go through these methods. The mutating methods, addMember() and removeMember() however, do a copy-on-write. That is, they first make a copy of the cache, add or remove the member key, and then replace the original cache with the copy. This permits multiple read and write threads to run concurrently without throwing ConcurrentModificationExceptions. But it still leaves open the danger of data races because nothing in this class guarantees serialized write access. You must impose this from without, either via explicit locking (GroupService.getLockableGroup()) or by synchronizing access from the caller.
@author Dan Ellentuck
@version $Revision: 19776 $
@see org.jasig.portal.groups.IEntityGroup
| |
| |
| |
| |
| |
| |
| |
| |