Another concurrency problem
Another concurrency problem
- Subject: Another concurrency problem
- From: John Larson <email@hidden>
- Date: Tue, 7 Aug 2007 09:59:26 -0500
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:
This email sent to email@hidden