RE: [Opensymphony-oscache] Deadlock using GeneralCacheAdministrator

Well the entire reason that lock in OSCache exists is to keep the creation 
of a new entry atomic (and hence prevent any other threads from creating the 
same object redundantly). Your workaround will have the (unwanted?) 
side-effect of sometimes allowing multiple threads to create the same cache 
entry. I can see the argument that OSCache should have a 3rd "no blocking at 
all" mode that allows this duplicated effort for new entries although I 
still think a more "correct" (and probably performant) solution would be to 
consistently obtain the locks in the same order. You could also provide your 
own 3rd lock that encompasses the other two; I don't know how practical that 
is for you to add to your codebase, or what impact that would have on 
performance.

IIRC the change required for OSCache to support this 3rd mode would be 
relatively straightforward to implement; if you're willing to submit a patch 
to Jira then perhaps this could make it in to CVS?



>From: rintcius <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: [Opensymphony-oscache] Deadlock using GeneralCacheAdministrator
>Date: Thu, 01 Sep 2005 07:39:07 CDT
>
>Well, it looks similar to the dining philosophers problem, but our problem 
>differs from it in the way that the dining philosophers is a conceptual 
>problem (in the sense that this problem cannot be solved as long as the 
>philosophers are working independently) whereas this problem can be solved 
>conceptually (the workaround that I mentioned seems to work ok).
>Therefore, I think that it should be possible to solve this problem inside 
>oscache (but it may clash with how oscache is currently implemented). Viz, 
>a (very naive) solution would be to simply incorporate the workaround code 
>into oscache.
>
>---------------------------------------------------------------------
>Posted via Jive Forums
>http://forums.opensymphony.com/thread.jspa?threadID=6334&messageID=14287#14287
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>