is MethodInterceptor thread-safe?

[Anthony MULLER]

Hello,

I'm using "method interceptor" mechanisms with Guice 1.0 and I wish to
know if it is thread-safe? (I have some strange behaviours in
multithreading environment)

Regards,
Anthony MÜLLER

[Fred Faber]

Your suspicions are correct:  an interceptor may be invoked by several threads concurrently.  For instance:

class TimingInterceptor implements MethodInterceptor {

  private final Stopwatch stopwatch;

   

   TimingInterceptor(Stopwatch stopwatch) {

       this.stopwatch = stopwatch;

    }

  @Override Object invoke(MethodInvocation i) throws Throwable {

       stopwatch.reset();

       try {

         return i.proceed();

       } finally {

          System.err.println("Invocation time: " + stopwatch.get());

      }

  }

Is going to break, because the stopwatch is shared among threads.

-Fred

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To post to this group, send email to google...@googlegroups.com.
To unsubscribe from this group, send email to google-guice...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.

[Anthony MULLER]

Thanks very much for your reply. Do you know if this issue is tracked?

Is it fixed in Guice 2.0?

Regards,
Anthony MÜLLER

2011/1/24 Fred Faber <ffa...@faiser.com>:

[Fred Faber]

Hi again,

I don't know that this is a defect, other than a case of needing to know that an interceptor is a singleton.  If its logic needs to be thread safe then it can define mutexes appropriately.  I don't know that I'd expect it to behave any differently :/

-Fred

[Colin Decker]

This is not an issue to be "fixed". You just have to consider the thread-safety of interceptors like you would any other object you write, with additional consideration to the fact that a single interceptor can be intercepting for multiple objects at the same time depending on what it's set up to intercept and how those bindings are scoped. Generally, you should probably write interceptors that are completely thread-safe.

Colin

[Anthony MULLER]

Ok... And is a methodinterceptor reentrant? In other words, can the
instance of MethodInvocation provided to the invoke method be updated?

Anthony

2011/1/24 Colin Decker <cgde...@gmail.com>:

[Colin Decker]

If I'm understanding you correctly, no. Each time an intercepted method is called a new (effectively immutable) MethodInvocation object is created and passed to the chain of MethodInterceptors that match that method.

Colin

[TJ Rothwell]

IMHO, this might be a confusion/consistency thing.

With guice-servlet, binding a servlet requires that it be bound in singleton scope, either explicitly or by annotation.

Note: Every servlet (or filter) is required to be a @Singleton. If you cannot annotate the class directly, you must bind it using bind(..).in(Singleton.class), separate to the filter() or servlet() rules. Mapping under any other scope is an error. This is to maintain consistency with the Servlet specification. Guice Servlet does not support the deprecated SingleThreadModel. http://code.google.com/p/google-guice/wiki/ServletModule

 

 It would make sense to be consistent for the method interceptor and require the same thing, this may reduce confusion.

Cheers,

-- TJ

[Sam Berlin]

On Mon, Jan 24, 2011 at 10:50 AM, TJ Rothwell <tj.ro...@gmail.com> wrote:

IMHO, this might be a confusion/consistency thing.

With guice-servlet, binding a servlet requires that it be bound in singleton scope, either explicitly or by annotation.

Note: Every servlet (or filter) is required to be a @Singleton. If you cannot annotate the class directly, you must bind it using bind(..).in(Singleton.class), separate to the filter() or servlet() rules. Mapping under any other scope is an error. This is to maintain consistency with the Servlet specification. Guice Servlet does not support the deprecated SingleThreadModel. http://code.google.com/p/google-guice/wiki/ServletModule

 

 It would make sense to be consistent for the method interceptor and require the same thing, this may reduce confusion.

That would significantly reduce the functionality & application of method interceptors.  IMO, it's really quite simple:  A method interceptor intercepts a call to a method.  How & when that method is called is up to your code.  If your code can call a method from multiple threads, your interceptor has to be aware & account for that.

sam

[Colin Decker]

To use MethodInterceptors, you already have to create an *instance* of the MethodInterceptor yourself and associate it with methods that should be intercepted using Matchers. They aren't given any Guice scope at all since they aren't created by Guice. I don't see how Servlets are relevant here.

Colin

On Mon, Jan 24, 2011 at 10:50 AM, TJ Rothwell <tj.ro...@gmail.com> wrote: