Multiple threads unable to share common refresh token in Java Spring OAuth2

I have a Java application that is running within the Spring 3.x framework and utilizes the off-the-shelf Spring OAuth2 implementation (JDBC persistence). My application exposes a REST interface that will be used by partners. Those applications will have a variable number of threads all hitting my application. 'Variable' is the key thing here. Ideally, I would like a single refresh token to be used per partner (in this case, the partner is the end user; they are not working on behalf of a common 'user'). What I am finding, however, is that if thread A requests an access_token from my server, token_A is returned. That is fine, but if thread B then requests a token, token_A is invalidated and token_B is returned. This obviously breaks thread A.

I have read through the RFC and I do not readily see that a second call to obtain an access_token should automatically issue a new token versus returning an existing, but still valid, token. This is actually how the 'implicit' grant_type flow works, but not the 'refresh_token' grant_type flow. I have pulled the GitHub source for DefaultTokenServices and it seems like the behavior is immutable and, I guess, desired. So, I have two questions:

1. Is issuing a new token (and therefore invalidating an older one) both mandatory and desired?
2. How to I get myself out of this problem? There must be multiple scenarios where multiple threads are sharing a single refresh_token. How do they work?

The ideal flow, as I see it would be something like this:

1. Thread A requests a token. None is found so a new token is created/returned. Validity period is 10 minute.
2. Thread A starts its processing, something that requires multiple requests and will take 8 minutes to complete
3. Thread B requests a token 7 minutes later. The token issues in #1 is still valid so that is returned; this token is now valid for 3 more minutes.
4. Thread B starts its procession, something that will take 5 minutes and multiple requests to complete
5. Three minutes into thread B's processing, target will return a 'not authorized' when the token granted in #1 expires. Thread B has 2 more minutes worth of processing to complete
6. Thread B requests a new token, which will be granted and which will be valid for 10 minutes
7. Thread B finishes the last 2 minutes worth of processing using the new token.