hi marcel, i have opened a jira issue
https://issues.apache.org/jira/browse/JCR-1334 and attached the logs please take a look at the logs thanks, claus -----Ursprüngliche Nachricht----- Von: Marcel Reutegger [mailto:[EMAIL PROTECTED] Gesendet: Montag, 21. Jänner 2008 11:09 An: [email protected] Betreff: Re: AW: Deadlock in XA Environment Hi Claus, if you were using 1.4 you could extend the DefaultISMLocking class and add logging to the methods. e.g. log the thread name. then configure and use the new locking class in repository.xml. this would at least allow us to rule out (or prove) the different thread assumption. regards marcel KÖLL Claus wrote: > hi marcel, > > ok thanks for the info. > i think its a websphere specific "featrure" ;-) > do you have any ideas what i have to test to find out what happens exactly ? > > BR, > claus > > -----Ursprüngliche Nachricht----- > Von: Marcel Reutegger [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 18. Jänner 2008 11:03 > An: [email protected] > Betreff: Re: Deadlock in XA Environment > > > KÖLL Claus wrote: >> we have some time now jackrabbit (1.3) running in our pruduction environment >> but >> without xa enabled. We are running on websphere 5.1 and i have configured >> now a j2c resource adapter >> for jackrabbit. it works fine till i try to modify a node in the repository >> in a global transaction. >> if i only try a search everything works fine. >> >> i have taken a thread dump with the deadlock situation. >> what i can see comes the deadlock from the DefaultISMLocking$ReadLockImpl >> Class >> hope somebodycan help .... > > hmm, this looks strange. there is only one thread that is trying to downgrade > its write lock. the only reason I can think of why this may block is that > downgrade is called from a different thread than the initial write lock > acquire. > > regards > marcel >
