With 4.3, CloudStack introduces a new concept called CallContext.  It is a little bit rehashed from UserContext in 4.2 but it's somewhat different.  This gives you some information about the what, why, and how about CallContext.

Why not UserContext

The usage of UserContext was inconsistent.  Sometimes, it's there, sometimes it's not there.  The account id can be changed by code at any time so some of the code just sets it themselves.  When the usage pattern of code is inconsistent, it basically means it's rather useless.  It's also rather misnamed.

Why CallContext

The idea for CallContext is to make the context of a call consistent and consistently available.  It guarantees the following things:

• A context id to track a task throughout that task's life.
• It includes the user id and account id of who made the call.
• It includes a storage that allows code to add objects into context and retrieve within the same thread.
• When activated, it adds into log4j the context id so logs can be easily tracked.
• All packages in CloudStack, other than utils, api, and engine-schema, must be able to access CallContext.
• Only SystemContext can imitate user contexts.

This means the following things for CloudStack code

• Frameworks are responsible for transporting CallContext across threads and processes.  
• Business logic should not need to think about how to access CallContext, it is always just there for you to use.  This reduces security errors and other branching in business logic.  
• Schema code should never access CallContext because schema is a translation layer and not part of business logic.
• All thread entry points need to register the proper CallContext and unregister it when it is done.

What have been done and needs to be done.

• In the vmsync branch, jobs framework have already been changed to work with CallContext.  I will be moving these changes to master as things go along.
• Ipc framework and events framework needs to add this.