On Apr 22, 2008, at 8:43 AM, [EMAIL PROTECTED] wrote:
I have went through the link you have provided some time back and
tried
kill -3, but it is not outputting any ino, command is just quitting
quietly.
Use jstack to produce stack dumps of all threads in a Java process.
Can you advise what sort of things I need to check in my app, which
may
cause these issues, such that we can have a resolution asap. I mean
any
code blocks/ design/ ?
Improper locking of EOF objects (e.g., EOEditingContexts) is a common
cause of deadlocks. All EOEditingContexts other than the WOSession's
defaultEditingContext() must be locked prior to access and unlocked
after. If you don't use Project WOnder, consider using
MultiECLockManager (<http://wocode.com/WOCode/Files/MultiECLockManager.java
>) to handle the locking of editing contexts stored as WOComponent
instance variables.
For editing contexts stored as local variables:
EOEditingContext ec = new EOEditingContext();
ec.lock();
try {
// Use ec
}
finally {
ec.unlock();
}
Also, improper locking of EODatabaseContexts and
EOObjectStoreCoordinators can cause deadlocks.
If your karma isn't quite what it should be, you could be victimized
by a WO bug that can cause deadlocks. Subclass
EOObjectStoreCoordinator and override addCooperatingObjectStore to
workaround this bug:
public class ObjectStoreCoordinator extends EOObjectStoreCoordinator {
@Override
public void addCooperatingObjectStore(EOCooperatingObjectStore
anObjectStore) {
if (cooperatingObjectStores().indexOfIdenticalObject(anObjectStore)
== NSArray.NotFound) {
if (anObjectStore.coordinator() != null) {
throw new IllegalStateException("Cannot add " +
anObjectStore +
" to this EOObjectStoreCoordinator because it already has
another.");
}
super.addCooperatingObjectStore(anObjectStore);
}
}
}
Set your EOObjectStoreCoordinator subclass to be the default object
store coordinator in your Application constructor:
EOObjectStoreCoordinator.setDefaultCoordinator(new
ObjectStoreCoordinator());
If you override WOSession.terminate(), ensure that an exception won't
prevent super.terminate from being invoked:
public void terminate() {
try {
// Do stuff.
}
catch (final Exception anException) {
// Handle exception.
}
finally {
super.terminate();
}
}
An exception thrown late in a request-response loop can cause
deadlock in some WO versions. A workaround in Application:
@Override
public void saveSessionForContext(WOContext aContext) {
try {
super.saveSessionForContext(aContext);
}
catch (final Throwable t) {
sessionStore().checkInSessionForContext(aContext);
}
}
All Java processes are multithreaded. If you don't protect shared
resources from concurrent access by multiple threads, deadlock can be
one consequence. I've got the battle scars to prove it.
Aloha,
Art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
