Question

we have been using ThreadLocal so far to carry some data so as to not clutter the API. However below are some of issues of using thread local that which I dont like

1) over the years the data items being carried in thread local has increased
2) Since we started using threads (for some light weight processing), we have also migrating these data to the threads in the pool and copying them back again

I am thinking of using an in memory DB for these (we doesnt want to add this to the API). I wondering if this approach is good. What r the pros and cons.

ok here is a simple scenario

1. user logs in and submits a request
2. system establishes context for this entire request which include
   – unique id for this request
   – username
   – system looged in (user can log into multiple systems)
   – some DOMAIN EVENTS for later use
3. the request passes through multiple logical layers (presentation, business domain,
   rules, integration) etc
4. in the integration layer, we borrow few threads from pool to parallel pull data from
   multiple partners. each of the pulls need some data stored earlier in thread local, so we migrate those to the pooled threads
5. after all data is received from partners, we migrate back the new thread local data accumulated in the child threads to the main thread
6. at the end of the interaction we persist the DOMAIN events to DB

Answer 1

you may want to introduce a request context: http://www.corej2eepatterns.com/Patterns2ndEd/ContextObject.htm

you can handle creation/destruction of such an object in a Filter if you’re using a WebContainer or an Interceptor if you’re using an ApplicationServer.