Hi Phillippe,
Short Story: I have not had a chance to get back to this - just been too busy -
and I have been using my quick-fix anonymous subclass as shown in that patch
for my abstract task superclass.
Long Story:
That patch will not be implemented because it is not architecturally clean
The question is mainly for Kieran.
In the framework COScheduler (job scheduling), I expose an abstract method
newEditingContext() to let the developer create his own ec with autolock =
false (see discussion in february 2010) like this:
@Override
public EOEditingContext
Because ERXLongResponseTask, which I don't use, uses auto lock/unlock, just
like a request thread.
That code is useful for plain old java task Threads that implement Callable or
Runnable and do not extend ERXLongResponseTask. It is also useful for any other
time you don't want an autolocking
http://issues.objectstyle.org/jira/browse/WONDER-478
On Feb 19, 2010, at 11:44 AM, Kieran Kelleher wrote:
Because ERXLongResponseTask, which I don't use, uses auto lock/unlock, just
like a request thread.
That code is useful for plain old java task Threads that implement Callable
or
Thank you VERY much... I'll use it right away!! :-D
On Feb 19, 2010, at 2:07 PM, Kieran Kelleher wrote:
http://issues.objectstyle.org/jira/browse/WONDER-478
On Feb 19, 2010, at 11:44 AM, Kieran Kelleher wrote:
Because ERXLongResponseTask, which I don't use, uses auto lock/unlock,
Thanks Kieran, Ricardo, Anjo, Jon.
Kieran, I follow your lead actually.
I don't have too many threads/classes (just 3 classes) so I just modified my
editingContext() in the classes like that:
protected EOEditingContext editingContext()
{
if (editingContext ==
Philippe,
This isn't the same thing. Between the line that creates and the line that sets
autolock to false below, another thread could call a method that triggers an
autolock.
If you can find the old discussion on this, you will see that I was actually
doing sth like you have shown here and
Does this apply to ERXLongResponse pages? I have a report that I moved to an
ERXLongResponse page and now the app hangs occasionally. Could this be a
locking issue?
Thanks, Steve
On Feb 17, 2010, at 5:21 PM, Anjo Krank wrote:
You *can* pass EOs between threads. You just really, wanna make
I demand a WOWODC session about locking, this is one thing that popup
every week in the lists :-)
Does this apply to ERXLongResponse pages? I have a report that I
moved to an ERXLongResponse page and now the app hangs occasionally.
Could this be a locking issue?
Thanks, Steve
On Feb
A long response most of the time locks in start and unlocks on end. If you use
the session EC for... well, you figure it out.
Cheers, Anjo
Am 18.02.2010 um 22:09 schrieb Steve Peery:
Does this apply to ERXLongResponse pages? I have a report that I moved to an
ERXLongResponse page and now
That could explain a few things.
Thanks, Steve
On Feb 18, 2010, at 4:20 PM, Anjo Krank wrote:
A long response most of the time locks in start and unlocks on end. If you
use the session EC for... well, you figure it out.
Cheers, Anjo
Am 18.02.2010 um 22:09 schrieb Steve Peery:
Hi all,
I get an issue with a multi threaded application. To be easier to understand,
my description is simpler than the reality but that's enough to see what's
going on I guess.
I'm using:
WO 5.4.3
Snow Leopard/ java 6
Wonder (not the very last but not old)
I put the following properties:
Some tidbits that might help:
1) Don't pass EOs between threads. Pass their EOGlobalIDs and use
ec.faultForGlobalID to rehydrate them in an ec in the thread that needs them.
Use Wonder ERXEOSomethingUtilities.convertEOtoGID if desired. (Something =
'Access' or 'Control', I can never
Hmm... I'm using background threads in my apps to do some processing. The
thread creates is editing context for its own use. Something like this:
EOObjectStoreCoordinator parentObjectStore = new
EOObjectStoreCoordinator();
editingContext =
You *can* pass EOs between threads. You just really, wanna make sure your
threads don't block each other (and do proper locking, auto may not be good
enough). In particular, you don't wanna use the session EC in a long running
thread.
Cheers, Anjo
Am 17.02.2010 um 21:23 schrieb Kieran
Ricardo J. Parada wrote:
Hmm... I'm using background threads in my apps to do some processing.
The thread creates is editing context for its own use. Something
like this:
EOObjectStoreCoordinator parentObjectStore = new
EOObjectStoreCoordinator();
editingContext =
Am 17.02.2010 um 23:18 schrieb Ricardo J. Parada:
2) If you have autolocking on and if you are using ERXEC.newEditingContext,
you may get deadlocks.
How so?
Cheers, Anjo
___
Do not post admin requests to the list. They will be ignored.
17 matches
Mail list logo
