CallContext and others

[Darren Shepherd <da...@gmail.com>]

In order to manage the database context at the bottom of the stack I'm 
having to create a small framework that does stuff as the code enters 
the managed context and leaves.  So the easiest way to use the framework 
is if you have

new Runnable() {
	public void run() {....}
}

in your code somewhere you just instead just do

new ManagedContextRunnable() {
	public void doRun {...}
}

Additionally for places where there is no runnable at the bottom of the 
stack (like ApiServer), there is a simple API as below.

public interface ManagedContext {
     public void runWithContext(Runnable run);

     public <T> T callWithContext(Callable<T> callable) throws 
Exception;

     public void registerListener(ManagedContextListener<?> listener);

     public void unregisterListener(ManagedContextListener<?> listener);
}

The (un)register methods are for registering listeners to do stuff as 
things enter/leave the context (like setup the transaction, etc).

Now this gets to my question.  So this is yet another context thread 
local thing that needs to be setup.  So I'm somewhat trying to tie the 
CallContext, ServerContext, AsyncJobExecutionContext, and this together. 
  So the "managed context" framework is the central place to wire this 
all up.  Here's what I'm doing, tell me if its terribly bad.

CallContext:  One thing I see with the CallContext is that its really 
easy to register twice and then leak the NDC stack.  What I propose is 
that on entering the ManagedContext I will setup the CallContext with a 
context that has the user as system and the context id as random.  As 
people call register/unregister it will push/pop a CallContext on some 
stack and additionally push/pop the NDC.  When leaving the 
ManagedContext I will ensure that all CallContexts are pop'd off the 
stack, thus clearing the NDC.  This approach has the added benefit that 
by default the context will be setup as system and then all background 
tasks don't explicitly have to call register(...)

ServerContexts:  Just delete it?  Basically it seems to just open/close 
transaction and I'll be doing that anyhow.  It doesn't seem to really be 
used yet.  Maybe my "Manage Context" framework essentially is in the 
spirit of what that was going to be?

AsyncJobExecutionContext: Not too much, I can just ensure that the 
AsyncJobExecutionContext is cleared on exit.


On last thought (sorry this is long).  I also created the concept of a 
ManagedThreadLocal.  Its like one thread local to rule them all.  Thread 
locals are fine, but people forget to clear them.  So what you do is 
have a "managed thread local" that looks and acts just like a TL but is 
really tied to a master TL.  When the main context of the thread clears, 
the master TL is cleared and all associated managed TLs will be cleared 
too.  Then you don't ever leak TLs.

Darren