[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WO Deadlocking Summary, Resolution
- Subject: WO Deadlocking Summary, Resolution
- From: mmuller at perfect.com (Max Muller)
- Date: Tue Apr 16 16:15:59 2002
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1E59C.82DA5490
Content-Type: text/plain;
charset="iso-8859-1"
Hi,
Just out of interest, has anyone tried to override the method
protected boolean _lockDefaultEditingContext()
to return false on their WOApplication subclass? I know this is a 'bad'
thing to do in general, but for single threaded apps it should be fine.
Don't currently have a 5.1 box setup to test or I would try it myself.
Regards,
Max
-----Original Message-----
From: Anthony M. Ingraldi [mailto:a.m.ingraldi@xxxxxxxxxxxxx]
Sent: Tuesday, April 16, 2002 2:48 PM
To: Pierre Bernard
Cc: WebObjects Dev
Subject: Re: WO Deadlocking Summary, Resolution
On Tuesday, April 16, 2002, at 05:25 PM, Pierre Bernard wrote:
> I can't really see what's wrong with the stack traces you posted.
> It is perfectly normal for the session to lock the default editing
> context.
I didn't post all of the details relating to this problem in my
most recent message as I have already done so previously. I
realize that it is normal for the session to lock its default
editing context.
> If this leads to a deadlock this however means that there was a
> previous lock that was not released. Have you collected traces of
> prior lock aquistions? Were there any not made by the WO
> frameworks?
The traces I posted are in fact those corresponding to prior lock
acquisitions. All of the traces obtained in deadlock situations
pointed to WO framework code as the culprit leaving locks in place.
--
Tony Ingraldi
a.m.ingraldi@xxxxxxxxxxxxx
(757) 864-3039
_______________________________________________
WebObjects-dev mailing list
WebObjects-dev@xxxxxxxxxxxxx
http://www.omnigroup.com/mailman/listinfo/webobjects-dev
------_=_NextPart_001_01C1E59C.82DA5490
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: WO Deadlocking Summary, Resolution</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hi,</FONT>
<BR> <FONT SIZE=3D2>Just out =
of interest, has anyone tried to override the method </FONT>
</P>
<P><FONT SIZE=3D2>protected boolean _lockDefaultEditingContext()</FONT>
</P>
<P><FONT SIZE=3D2>to return false on their WOApplication subclass? I =
know this is a 'bad' thing to do in general, but for single threaded =
apps it should be fine. Don't currently have a 5.1 box setup to test or =
I would try it myself.</FONT></P>
<P><FONT SIZE=3D2>Regards,</FONT>
<BR> <FONT =
SIZE=3D2>Max</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anthony M. Ingraldi [<A =
HREF=3D"mailto:a.m.ingraldi@xxxxxxxxxxxxx";>mailto:a.m.ingraldi@xxxxxxxxx=
.gov</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 16, 2002 2:48 PM</FONT>
<BR><FONT SIZE=3D2>To: Pierre Bernard</FONT>
<BR><FONT SIZE=3D2>Cc: WebObjects Dev</FONT>
<BR><FONT SIZE=3D2>Subject: Re: WO Deadlocking Summary, =
Resolution</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>On Tuesday, April 16, 2002, at 05:25 PM, Pierre =
Bernard wrote:</FONT>
</P>
<P><FONT SIZE=3D2>> I can't really see what's wrong with the stack =
traces you posted. </FONT>
<BR><FONT SIZE=3D2>> It is perfectly normal for the session to lock =
the default editing </FONT>
<BR><FONT SIZE=3D2>> context.</FONT>
</P>
<P><FONT SIZE=3D2>I didn't post all of the details relating to this =
problem in my </FONT>
<BR><FONT SIZE=3D2>most recent message as I have already done so =
previously. I </FONT>
<BR><FONT SIZE=3D2>realize that it is normal for the session to lock =
its default </FONT>
<BR><FONT SIZE=3D2>editing context.</FONT>
</P>
<P><FONT SIZE=3D2>> If this leads to a deadlock this however means =
that there was a </FONT>
<BR><FONT SIZE=3D2>> previous lock that was not released. Have you =
collected traces of </FONT>
<BR><FONT SIZE=3D2>> prior lock aquistions? Were there any not made =
by the WO </FONT>
<BR><FONT SIZE=3D2>> frameworks?</FONT>
</P>
<P><FONT SIZE=3D2>The traces I posted are in fact those corresponding =
to prior lock </FONT>
<BR><FONT SIZE=3D2>acquisitions. All of the traces obtained in =
deadlock situations </FONT>
<BR><FONT SIZE=3D2>pointed to WO framework code as the culprit leaving =
locks in place.</FONT>
</P>
<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2> Tony Ingraldi</FONT>
<BR><FONT SIZE=3D2> a.m.ingraldi@xxxxxxxxxxxxx</FONT>
<BR><FONT SIZE=3D2> (757) 864-3039</FONT>
</P>
<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>WebObjects-dev mailing list</FONT>
<BR><FONT SIZE=3D2>WebObjects-dev@xxxxxxxxxxxxx</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.omnigroup.com/mailman/listinfo/webobjects-dev"; =
TARGET=3D"_blank">http://www.omnigroup.com/mailman/listinfo/webobjects-d=
ev</A></FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C1E59C.82DA5490--