Re: Help with stack trace from frozen application
Re: Help with stack trace from frozen application
- Subject: Re: Help with stack trace from frozen application
- From: Chuck Hill <email@hidden>
- Date: Thu, 10 Nov 2005 18:16:26 -0500
On Nov 10, 2005, at 11:43 AM, Marcos Trejo Munguia wrote:
Hello Lindesay:
A) If you are creating your own editing contexts, are you locking and
unlocking them appropriately?
B) Are you manually locking a "default editing context" from the
session? (if so, why?)
C) Could you be running out of memory handling a request?
A) I'm using my own editing contexts, and I'm locking them in
WOComponent's awake method and unlocking them in WOComponent's
sleep method
That is a most excellent way to deadlock your application! I'd
strongly suggest using the MultiECLockManager from WOCode or ERXEC
from Project Wonder. Otherwise, you should expect your application
to freeze periodically.
B) I'm only use the default editing context to read never to write,
and I'm not locking this editing context.
That is fine.
C) I'm not sure, Do I have to see a java.lang.OutOfMemoryError to
know for sure that I'm running out of memory? If the answer is yes
then I'm not having this problem, if is not then how do I know that
I'm running out of memory?
No, you won't always see this message. Usually, but not always.
When you don't see it the app usually also freezes. :-)
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden