Re: How does concurrency control work in WO?
Re: How does concurrency control work in WO?
- Subject: Re: How does concurrency control work in WO?
- From: Andrew Lindesay <email@hidden>
- Date: Tue, 31 Mar 2009 23:34:49 +1300
Hello Jeff;
I'd start with David's suggestions -- especially his comments about
actually getting the SQL-trace out and garnering an understanding what
it is doing. Despite all the WebObjects wizardry we have at our
disposal, at some point, if you need to read and write *really* large
quantities of data at the same time as "business as usual", you may
need to look at scaling opportunities at the database end.
cheers.
This is a very timely thread for me, and very interesting blog
entry. In my app, I get hit several times a day with the perfect
storm of having to deal with extremely high peak traffic from
users(mostly, but not all, read only) at the exact time that I have
to run a background thread that needs to rip through the database,
reading and updating a huge amount of data. The changes made by the
background task need to be made available to the users ASAP (that's
why they are there, they want their data and they want it now!).
After suffering through two of these peaks where the app response
and the background thread both got slower and slower until they
finally ground to a halt and required a reboot of the server, I
decided to put the app in maintenance mode (relegating users to the
main page) for the 20 or so minutes it takes the background thread
to complete, and then let everyone in. Doing it this way, the
background thread really rips through its calculations, and then the
server has no problem serving the high peak traffic with the
background thread out of the way. However I really don't like
having to lock people out several times a day at peak traffic. I
was wondering if there were some type of architecture that could be
used where this kind of case could be handled more smoothly, or
perhaps this is a sign of something I'm doing wrong at a lower
level. Note that it seems like the real problems occur when I have
two threads with two different OSC stacks (the background thread has
its own) hitting the same database at the same time. Could it be
something as simple as putting a delay in my background task? Note
that it is doing a lot of in memory calculations, so it's not like
it's constantly hitting the DB, although it does hit it pretty hard
I think. Would fetching raw rows in the background task really make
that much of a difference? It's still hitting (and locking) the
database, right? Anyway, just wondering if there are others dealing
with this type of situation and how they handle it?
___
Andrew Lindesay
www.lindesay.co.nz
_______________________________________________
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