Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23569

Re: DI/wiring

Show all headers | View raw

On 4/22/2013 12:03 AM, Daniele Futtorovic wrote:
>
> In code terms, instead of:
>    class Actor {
>      void act( Context c ){ doSomethingWith( c.getXXX() ); }
>    }

Just to be clear, I was advocating using constructors, not method 
parameters:

public class Actor {
   private Context c;
   public Actor( Context c ) {this.c = c}
   public void act() { doSomethingWith( c.getXXX() ); }
}

This is really really different:

> You'd have:
>    class Actor {
>      void act(){
>        doSomethingWith( ContextHelper.getThreadLocalContext().getXXX() );
>      }
>    }

Now actor does something different depending on what thread is invoking 
a method. My class was invariant with respect to the thread invoking its 
method.  No matter who calls "act()" the result will always be the same.

Since modern systems often use thread pools and the worker threads are 
supposed to be generic and often randomly assigned, I can't see too many 
cases where your thread local context is going to be useful.  Worse, if 
an generic worker thread has a context and then is assigned to another 
task... the results could be random and unpredictable, and really hard 
to debug as well.

I'm sure you must have some use case in mind where a thread local is 
useful, but I'm having a hard time seeing it.  It feels like you push 
the context/initialization problem into the threading system, where it's 
actually going to be harder to manage.  In a system that was designed 
from the ground up to support contexts attached to threads, OK it might 
work, but in many existing systems it seems difficult to add.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: DI/wiring markspace <markspace@nospam.nospam> - 2013-04-18 12:16 -0700
  Re: DI/wiring Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-04-22 09:03 +0200
    Re: DI/wiring markspace <markspace@nospam.nospam> - 2013-04-22 10:59 -0700
      Re: DI/wiring Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-04-24 06:37 +0200
      Re: DI/wiring Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-04-24 10:28 -0300

csiph-web