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
