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

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

Re: DI/wiring

Show all headers | View raw

On 04/22/2013 02:59 PM, markspace wrote:
> 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.
>
I can think of one right now, one that is in production in a fairly 
major J2EE/JEE system I am familiar with.

The idea was/is to implement a persistent conversation, and this 
implementation goes back about 7 years, in the context of JSF 1.x and 
JPA. Basically an application-managed entity manager needs to kept 
around, one for each application user, from a defined EM-creation 
checkpoint to a defined EM-commit/rollback checkpoint. This is needed 
because money is involved and the real-world scenario demands it. It is 
not possible to commit per-request, for much of the business state.

Between HTTP requests it's reasonable to keep a user's EM in their HTTP 
session. *During* requests the specific conversational EM assigned to 
that user must be made available wherever it's required in code - a very 
convenient way of doing that is to place the user EM into a ThreadLocal 
in the 1st JSF phase, in a helper class, and provide a getter to allow 
the user's HTTP request thread to retrieve that "special" EM as needed 
in any method.

I think you'll realize that something like an ApplicationScoped JSF 
managed bean would not work here. It's technically possible for B.L. or 
datalayer code to access a JSF managed bean, if you assume that that top 
layer is there, but it's an unpleasant picture. Much better to have the 
user EM's kept in a ThreadLocal in a data layer helper class, since that 
makes architectural sense.

I might add, this described implementation is pre-Servlet 3 and no async 
processing is involved.

AHS

Back to comp.lang.java.programmer | Previous | Next — Previous 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