[concurrency-interest] thread queueing qn

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


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

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

- 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

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,

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

More information about the Concurrency-interest mailing list