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

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

Re: Wormholes

Show all headers | View raw

On 05/09/12 20:51, Robert Klemme wrote:
> I knew finally someone would suggest ThreadLocal for this.  This might 
> be even worse than global variables, especially since you pass hidden 
> state which usually makes testing more difficult.

Quite; that's why I started with: "Assuming that you can't improve your 
structure or refactor, ..."  That is, others' advice is to be tried first.

> The proper approach would be to pass the state down the call chain.

You're probably right, but there's not enough information in the stated 
problem.  I'd recently experienced a specific version of the problem, 
and mentioned how it was solved.  For me, the "incommensurate ripples" 
would be a use-specific change in an API.

> IMHO the best usage for ThreadLocal is to cache state *inside a class* 
> if calls may be concurrent and the cost of creating the state is 
> significantly high.  But using it to pass information between classes 
> because one wants to avoid adding method parameters is asking for 
> trouble.

I'll be more specific with the example I gave.  Here's an abridged API 
for a hierarchical structure that can be serialized:

   abstract class Box {
     List<Box> children;
     abstract InputStream getFieldContent();

     final InputStream getChildContent() {
       List<InputStream> streams = new ArrayList<>(children.size());
       for (Box child : children)
         streams.add(child.getContent());
       return new SequenceInputStream(Collections.enumeration(streams));
     }

     final InputStream getContent() {
       return new SequenceInputStream(getFieldContent(), getChildContent());
     }
   }

Several library-defined extensions are provided, implementing 
getFieldContent() in various useful ways.

Outside the library, there's a user creating a custom box type, making a 
hierarchy including it, and caching it:

   class MyAppSpecBox extends Box {
     InputStream getFieldContent() {
       ...
     }
   }

   // Create hierarchy out of library Box extensions.
   Box root = ... ;

   // Add the custom box type somewhere in the hierarchy.
   Box myBox = new MyAppSpecBox();
   root.children.get(2).children.get(1).children.add(myBox);

   cache.store(key, root);

Fetch it later, and serialize it:

   Box root = cache.fetch(key);
   InputStream in = root.getContent();

Suppose we want MyAppSpecBox.getFieldContent() to use a context which is 
known only at the point of fetching from the cache.  We don't control 
the Box API, and even if we did, we couldn't add an application-specific 
parameter to the getContent() family of methods.  How would we add a 
generic one, one that would be usable by several users independently and 
simultaneously (other than the Context<T> class I suggested, which is 
just a variation on ThreadLocal<T>)?

If we could locate myBox from root, we could pass the context to it 
after fetching.  However, traversing the full hierarchy or even knowing 
the correct path seem clumsy ways to locate it.  Also, its storage of 
the context would not be thread-safe.

So, we throw in a ThreadLocal:

   static ThreadLocal<Context> context = ...;

   class MyAppSpecBox extends Box {
     InputStream getFieldContent() {
       Context ctxt = context.get();
       ...
     }
   }

We set it before invoking the hierarchy:

   Box root = cache.fetch(key);
   Context ctxt = new Context(...);
   context.set(ctxt);
   InputStream in = root.getContent();


> Also, you need to be aware that the lifetime of these objects can be 
> quite long (there was a discussion about various aspects of 
> ThreadLocal in light of thread pools here earlier).

That use of ThreadLocal was preserving state from one 'prong' of the 
stack to the next, presumably with no way to inject a 
ThreadLocal.set(null) at a common vertex of those prongs.  This use of 
ThreadLocal only pushes values up the stack, which allows us to be more 
rigorous:

   Box root = cache.fetch(key);
   Context ctxt = new Context(...);
   context.set(ctxt);
   try {
     InputStream in = root.getContent();
   } finally {
     context.set(null);
   }


Cheers,

Steven

-- 
ss at comp dot lancs dot ac dot uk

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

Thread

Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-03 18:12 -0700
  Re: Wormholes eric@invalid.com (EricF) - 2012-09-04 02:06 +0000
    Re: Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-04 10:08 -0700
    Re: Wormholes Wanja Gayk <brixomatic@yahoo.com> - 2012-09-09 13:55 +0200
  Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-03 22:34 -0400
    Re: Wormholes Stuart <DerTopper@web.de> - 2012-09-04 12:15 +0200
  Re: Wormholes markspace <-@.> - 2012-09-03 21:00 -0700
    Re: Wormholes Robert Klemme <shortcutter@googlemail.com> - 2012-09-04 07:08 +0200
  Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 08:47 +0200
    Re: Wormholes Lew <noone@lewscanon.com> - 2012-09-04 03:10 -0700
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 16:09 +0200
        Re: Wormholes Gene Wirchenko <genew@ocis.net> - 2012-09-04 08:34 -0700
          Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-04 17:46 +0200
            Re: Wormholes Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-04 09:31 -0700
        Re: Wormholes Lew <lewbloch@gmail.com> - 2012-09-04 11:14 -0700
        Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-04 19:59 -0400
    Re: Wormholes Roedy Green <see_website@mindprod.com.invalid> - 2012-09-04 13:20 -0700
      Re: Wormholes Arne Vajhøj <arne@vajhoej.dk> - 2012-09-04 20:00 -0400
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:01 +0200
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:02 +0200
      Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:02 +0200
        Re: Wormholes Zermelo <zermelo@teletu.it.nospam.invalid> - 2012-09-05 09:03 +0200
      Re: Wormholes markspace <-@.> - 2012-09-05 17:34 -0700
  Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-04 14:18 +0100
    Re: Wormholes Robert Klemme <shortcutter@googlemail.com> - 2012-09-05 21:51 +0200
      Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-05 23:26 +0100
        Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 09:32 +0000
          Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-06 11:47 +0100
            Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 15:10 +0000
              Re: Wormholes Steven Simpson <ss@domain.invalid> - 2012-09-06 20:12 +0100
                Re: Wormholes Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-09-06 21:08 +0000
  Re: Wormholes Nigel Wade <nmw@ion.le.ac.uk> - 2012-09-04 17:26 +0100
  Re: Wormholes Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-04 09:28 -0700
  Re: Wormholes David Lamb <dalamb@cs.queensu.ca> - 2012-09-04 16:54 -0400

csiph-web