We have a couple of WO/EOF based applications that use project wonder deployed
as servlets in Tomcat. One of the apps is a classic WO app that uses WO
components and a standard WO request/response loop. Our other 2 apps don’t use
WOComponents but do use EOF. Consequently the other 2 apps do not use the
regular WO request/response loop.
I have a couple of questions:
1. Looking into ERXEC it appears that when a new ERXEC is created it is bound
into the ThreadLocal variable. If that thread makes additional calls to
newEditingContext() it appears to always return the same ERXEC – is that
true/by design? It doesn’t seem to get a new ERXEC.
2. When using an ERXEC in a thread we typically do something like:
ERXEC ec = ERXEC.newEditingContext();
ec.lock();
try {
...
} finally {
ec.unlock();
}
Should we call ec.dispose() when we are done with the ec we created in
the scope of the method? Will that prevent the ec from being reused in
subsequent calls to the method by the same thread?
3. Will the built in autolocking/unlocking work correctly if the WO
request/response loop is not used? Should we disable the autolocking
functionality if we are not using the WO request/response loop? Are there other
settings that should be set if we do not use autolocking?
The reason I am asking these questions is that I am have some hanging issues in
the apps that do not use the WO request/response functionality. Tracing the
ERXEC locking behavior I can see there are cases where there are an UNEQUAL
number of lock and unlock operations. Usually the hung threads have an extra
lock operation. I suspect that is the root cause of my hung threads. It seems
that the reuse of editing contexts within a thread causes the mismatch in the
number of locks/unlocks.
Thanks in advance for any insights you can provide
Dov Rosenberg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
