On 8/9/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Stefano Bagnara ha scritto:
> > /**
> > * Method execute executes a Block within the context of a new
> > ConditionManager.
> > * @param mail
> > * @param block
> > * @return Object
> > * @throws SieveException
> > */
> > protected Object execute(MailAdapter mail, Block block) throws
> > SieveException {
> > // Switch to a new ConditionManager
> > ConditionManager oldManager = ConditionManager.getInstance();
> > ConditionManager.resetInstance();
> >
> > // Execute the Block
> > Object result = block.execute(mail);
> >
> > // Restore the old ConditionManager
> > ConditionManager.setInstance(oldManager);
> >
> > return result;
> > }
> >
> > I don't get how it works. ConditionManager.resetInstance will set the
> > static thread local fieldInstance to null: doesn't this invalidate also
> > instances of every other thread using the ConditionManager ? Shouldn't
> > resetInstance simply remove the conditionManager from the fieldInstance
> > ThreadLocal using a fieldInstance.set(null) ?
>
> Forgot to say that if this is the case it should be pretty easy to
> create a test case to prove it.
how would you approach the management of the multiple threads?
> Furthermore, I see that this block is allowed to send SieveException.
> Maybe the setInstance(oldManager) should be called in a finally to make
> sure we place back the status to the right one (well, maybe after an
> exception the ConditionManager is ignored, but I think it is anyway
> better to cleanup).
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
