[concurrency-interest] thread queueing qn

Dhanji R. Prasanna dhanji at gmail.com
Fri Jan 18 17:37:28 EST 2008


Hi

I am trying to sequence/queue HTTP requests in a semantic user
"conversation":


Incoming Request -> Filter (Identify by cookie or rewritten URL) -> Read( by
Id from ConversationStore ) -> setActive ( ConversationContext )



Each conversation is modeled as a ConversationContext object that may be
stored in a permanent storage medium (custom impl by a user). My solution is
to obtain the ConversationContext from a store (creating a new one as
necessary) and then synchronizing on it while processing the request:


doFilter( ...) {


   ConversationContext con = readFromStoreById(..);

   synchronized(con) {
         filterChain.doFilter(...);     //process request normally
   }


}



This gives me queueing so that no two requests belonging to the *same* user
conversation are processed concurrently. However I see a couple of
drawbacks:

- synchronizing on a public object from a store is potentially dangerous, as
poorly written user impls can deadlock or starve request threads
- as an alternative, I don't want to force/trust users to expose a locking
API




One alternative I thought of was to keep a private registry of active
conversation keys (j.u.c.l.Locks in a hashtable) and lock the keys instead.
These work for the majority of cases, but there are times when a
conversation needs to be "merged" into a prior context, say from the
permanent store (key "collapsing", if you will). In this case the locks need
to be merged too--what is the best way to do this?

And does anyone have a better solution than locking by keys?

Thank you,

Dhanji.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080119/7a68c706/attachment.html 


More information about the Concurrency-interest mailing list