0

I am using approach from the "Accessing scoped proxy beans within Threads of" answer. However I am seeing rare deadlocks involving RequestAttributes object. The main reason of the deadlock is between the synchronized (this.sessionAttributesToUpdate) statement in the object and servlet session hash-map. Normally the instances of the object are created for each request, so they don't clash, but if I pass the object to another thread to use the session beans, the same object is used and it causes deadlock sometimes.

The deadlock happens if current http request is not completed while the another thread starts using a session bean passed with RequestContextHolder.setRequestAttributes.

I think this guy mentions the same problem, but his question is unanswered: Session scoped bean encountering deadlock.

So, any ideas how to avoid the deadlock?

Community
  • 1
  • 1
kan
  • 28,279
  • 7
  • 71
  • 101
  • 1
    Can you explain a bit more what you do in your thread? (perhaps there is another solution to the problem you are trying to solve) Having a look at the approach at link you posted, it seems logically wrong to me. Especially attempts to call set* methods on request/session objects that may no longer exist at the moment they're called. Accessing objects that are in a session from a background thread seems like a wrong pattern to me (I might be mistaken though). – Krešimir Nesek Apr 02 '13 at 16:47
  • @KresimirNesek The thread does some small, but time consuming background job to load some data while a user is navigating between pages. Kind of a prefetch mechanism. Yes, I know running threads from http requests is not great thing to do, but at the moment it is only viable solution in our project. – kan Apr 02 '13 at 17:28
  • It's ok to start threads from requests, but I don't know if using session directly is good idea to transfer/sync parameters and results. Session might not even exist when threads are completed etc. Anyhow I posted some alternative suggestions in the answer. Hope it helps! – Krešimir Nesek Apr 02 '13 at 18:02
  • 1
    @Kresimir: note that it's absolutely not OK to start **unmanaged** threads from requests. – BalusC Apr 02 '13 at 19:06
  • @BalusC Agreed. Should have pointed that out in the comment. – Krešimir Nesek Apr 02 '13 at 19:17
  • @KresimirNesek I don't work with session directly, it is used by session scoped bean from Spring. The threads are not unmanaged, they executed by WorkManager from WebSphere. – kan Apr 02 '13 at 19:56

1 Answers1

0

Here's an answer that provides alternative solution considering the objective is to calculate something in background while user is navigating pages.

Possibility 1: Create a service bean with processing method that is annotated with @Async (http://static.springsource.org/spring/docs/3.0.x/reference/scheduling.html) that returns a result of computation in a Future object. Store the Future object in the session. Access the result in subsequent requests through Future object if task is completed. Cancel the the task via Future.cancel if session is to be destroyed before task is completed.

Possibility 2: Take a look if new features of Spring 3.2 and Servlet 3.0 async processing can help you: http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-ann-async

Possibility 3: Emulate a task queue. Create a singleton service that can put objects to structure like ConcurrentMap where key would be some job id (you can than store key into session) and value the result of background processing. Background thread would then store objects there (this is perhaps not much better than accessing session directly, but you can make sure it's thread safe).

Krešimir Nesek
  • 5,302
  • 4
  • 29
  • 56
  • 1. Do you know if the async call would inherit session beans? And moreover, I need to use WorkManager from WS, I don't need yet another thread pool. 2. As I understand, it is for a long running request, I need something to do between requests. 3. Yes... and then need to maintain leaks if session died... – kan Apr 02 '13 at 21:01
  • 1
    1. It seems it won't work according to this https://jira.springsource.org/browse/SPR-6873 :( – Krešimir Nesek Apr 02 '13 at 22:50