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: Fri, 11 Nov 2005 20:06:08 -0500
On Nov 11, 2005, at 7:49 PM, Marcos Trejo Munguia wrote:
Thanks again Chuck.
I'm going to use MultiECLockManager because I'm not using Project
Wonder at all, but now let me ask you one final question, where in
WOComponent subclasses do I have to register/unregister editing
contexts with MultiECLockManager?
What I do is add a newEditingContext() method to session. This
returns a locked ec from the MultiECLockManager Then in the
constructor of pages that need an editing context, I add
ec = ((Session)session()).newEditingContext();
Let garbage collection handle the unlocking / cleanup.
Chuck
On Nov 11, 2005, at 5:25 PM, Chuck Hill wrote:
On Nov 11, 2005, at 5:11 PM, Marcos Trejo Munguia wrote:
Thanks for your replies Chuck and Lindesay.
One last question Chuck, which one you'd recommend me the most,
MultiECLockManager or ERXEC?
That depends. :-) If you are using other parts of Project
Wonder, then ERXEC is almost certainly the way to go. If you are
just getting started in your application, Project Wonder will
bring many benefits. If you are not using Project Wonder, and
want to avoid any integration costs, then MultiECLockManager
requires very little to include in your application. As far as I
know, they both provide an equal level of protection again
unlocked access and against deadlocks due to improper lock usage.
Chuck
On Nov 10, 2005, at 5:16 PM, Chuck Hill wrote:
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
--
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
--
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