In an application we work with threads, but for ease of usage, we may not want to pass around the same objects all the time. It helps in our method signature, signifying the objects we perfrom our function on, but sometimes, it feels rather unnecessary.
For example, let's assume we have a request-id which we recieve, and want to pass to all outgoing requests. Or we want to prevent a certain query being performed multiple times by caching the result.
These are request-scoped data items. Since every request runs in it's own thread, we can use threadlocals.
In spring, we can do a bit better, by using a
https://dzone.com/articles/an-alternative-approach-to-threadlocal-using-sprin-1
This allows us to get a thread-instance per request, which can be injected into our services without any knowledge of caching occuring.
In essence, we create some sort of thread-tied global object. This is, of course, something which can be easily abused, and can lead to hard to follow code. But, it can also clean up a bit of nasty code, so we should use it if we must.
For example, let's assume we have a request-id which we recieve, and want to pass to all outgoing requests. Or we want to prevent a certain query being performed multiple times by caching the result.
These are request-scoped data items. Since every request runs in it's own thread, we can use threadlocals.
In spring, we can do a bit better, by using a
ThreadLocalTargetSource https://dzone.com/articles/an-alternative-approach-to-threadlocal-using-sprin-1
This allows us to get a thread-instance per request, which can be injected into our services without any knowledge of caching occuring.
In essence, we create some sort of thread-tied global object. This is, of course, something which can be easily abused, and can lead to hard to follow code. But, it can also clean up a bit of nasty code, so we should use it if we must.
Reacties
Een reactie posten