Hi, >> Why would that be a problem? By definition we should not be having >> more than one concurrent thread accessing such blocks. > because the synchronized blocks may become too big, which is > always fragile.
What do you mean with 'too big' and 'fragile'? > then, why not synchronizing on access to the namespace map ? or isn't > this possible ? I don't know about the namespace map, but sometimes synchronizing on a lower level means more monitor entry and exit operations, which could be slower. Also it could be harder to implement correctly. > well, this is an interesting point ;-) While I think a service may > account for some client problems, it may not account for all problems. > Most notably, if a client is violating the contract, the client should > get into trouble -- the sooner the better If 'get in trouble' means throwing an exception (ConcurrentModificationException) then I agree. However it is very problematic if 'get in trouble' can mean a corrupted repository, a non-atomic transaction. Regards, Thomas
