Hi all, I'm trying to track down some weird behavior that keeps popping up through the monkeys for the RIFE continuations tests. I've before already stumbled into unexpected behavior when TC has to lock on synchronization blocks that are nested at various levels and I worked around it by splitting the code blocks up in various parts (which isn't ideal). Before I go any further in trying to isolate it, I was wondering if there are already known problems with this or specific situations that are unsupported?
Just to give a taste for what I'm talking about (please don't judge the horrible length of this method, it kinda grew over time, I never get 'round to refactoring it): http://rifers.org/fisheye/browse/rifers/rife/trunk/src/framework/com/uwyn/rife/engine/ElementContext.java?r=3791#l243 There are several synchronized blocks there on mElement. If I remove them all and do one big synchronized block on mElement for the entire method, I get UnlockedSharedObjectExceptions on objects that are clearly inside the lock (for instance at mRequestState.clearRequest() in the finally block, line 826). Thanks for any insights and help, Geert -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
