You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Warwick Burrows <wa...@e2open.com> on 2004/10/27 02:27:32 UTC

Solved my hang problem with DB2

Hi,
 
The problem was that some of the action related methods in the SecurityImpl
class were not "enlisted" to the current transaction when they made db
calls. The "Uri" object instance that was being used to call the store's
retrieve interface didn't have the current SlideToken set because the Uri
was being created with getUri(String) and not getUri(SlideToken, String).
Without the current token set the Uri assumes that there is no current
transaction going on and gets another connection to make its requests on. It
seems that it was eventually blocking waiting for the transaction to
complete but the transaction could not complete until it had performed its
db reads. So I modified the path to loadActions() called from the
matchAction() method which takes a SlideToken and passed this token through
to loadActions() setting Uri's with the getUri(String) with
getUri(SlideToken, String) when I found it. I also fixed the call path to
loadActions() that came from the PropertyHelper classes.
 
I will submit a defect for this and the patch files to bugzilla.
 
There are some other places where getUri(String) is used, eg.
getActionNode() in the NamespaceConfig class and hasPermission() in the
SecurityImpl class. The former is called only during initialization when it
seems that there is no token around to use. But in the latter case
hasPermission() does make calls to the store using three different Uris it
constructs. So for those using the access control these calls may result in
a deadlock just as happened in my case.
 
Warwick