Hi, Jukka Zitting schrieb: > On Wed, Oct 8, 2008 at 4:06 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: >> I have the vague guts feeling, that this is not a good idea because it >> creates too big synchronized blocks. > > Why would that be a problem? By definition we should not be having > more than one concurrent thread accessing such blocks.
ehrm, because the synchronized blocks may become too big, which is always fragile. > >> Therefore I would think, that this is probably not a good idea to do. It >> would probably be better to enhance JavaDoc and tell "not thread-safe" >> in big fat red letters. > > The background to this issue is a ConcurrentModificationException that > Angela spotted on the namespace map in AbstractSession. That map is > only ever accessed and modified by public Session methods, so the only then, why not synchronizing on access to the namespace map ? or isn't this possible ? > way for that exception to occur is if some client is already breaking > the thread-safety contract of Session. That's clearly a bug in the > client code, but IMHO relying on the correctness of client code is too > fragile. 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 .... But then, of course, YMMV. Regards Felix
