Re: Another concurrency problem
Re: Another concurrency problem
- Subject: Re: Another concurrency problem
- From: Kieran Kelleher <email@hidden>
- Date: Tue, 7 Aug 2007 12:07:05 -0400
Hi John,
Just some general comments:
1) Mike Schrags advice of using GlobalIDs for passing around EO's
between threads is good advice.
2) Use a separate ObjectStoreCoordinator for your background thread
to avoid locking conflicts
3) Use Wonder's ERXObjectStoreCoordinator to automatically
synchronize OSC stacks.
4) Possibly a better order scheduling trigger design might be to have
the order scheduled by overriding WOnder's ERXGenericRecord.didInsert
() at which time you are sure the object has been just saved to
database.... a lot of useful transition methods there did* and will*.
HTH, Kieran
On Aug 7, 2007, at 10:59 AM, John Larson wrote:
I read the recent post on a concurrency problem and wondered if it
is similar to a problem that I recently ran into, or maybe I'm just
making another EC mistake.
I have a background thread that does background order scheduling.
It needs to be kept abreast of specific changes in objects. The
scheduler has its own erxec and the changes I'm looking for are
made in normal session rr cycles. When the change is made, the
session thread makes an entry in a message queue in the scheduler
(ie the qty on hand for this stock code has changed to this number).
Upon processing the message, the scheduler gets a local instance of
the object and does its thing. The session thread, after putting
the message in the queue, goes on and finishes the response and
saves the ec. This happens asynchronously because the update in
the scheduler can take some time.
Most of the time eveything was fine, but I nailed the problem down
to the fact that I was calling takestoredvalueforkey for the qty on
hand for the stock code in the scheduler. I did this because I
overrode the setter to add the message to the scheduler's queue.
If I used the setter in the scheduler, then I'd get locked in a
loop since it would make another message for the scheduler ad
infinitum. Also, I didn't know if the session had saved its ec so
I couldn't be sure that the scheduler's instance of the stock code
would have the new qty on hand.
Before the scheduler processes the message,I'd lock the ec without
a problem. But the entire app would occasionally freeze on
takestoredvalueforkey. I changed the code to save the ec before
sending the message and eveything is fine.
The thing that leaves me feeling icky is that I'm calling
takestoredvalueforkey in the setter that the session thread is
using too. I have it working now, but have the feeling that I'm
missing something big here with regard to thread/ec safety.
Any comments?
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
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