Re: new EOObjectStoreCoordinator and closing database connection afterwards
Re: new EOObjectStoreCoordinator and closing database connection afterwards
- Subject: Re: new EOObjectStoreCoordinator and closing database connection afterwards
- From: Kieran Kelleher <email@hidden>
- Date: Fri, 13 Nov 2009 07:59:13 -0500
With this particular app, where "Direct Mail Advertizing" services are
provided to about 3000 customers, there is a lot of editing/saving by
all users and a *lot* of background thread processes invoked by user
actions, for example activities such as performing US Postal Hygiene
(CASS/DPV/NCOA) processing on user lists. These tasks may last 30
seconds or up to 10 minutes. The long request logs of the useful
ERXStatisticsStore clearly show that these background processes can
slow down other user EOF activity in regular requests. So these OSCs
are short-lived. I have seen connections rise to about 140 during days
where many of the activity involved these data processing
tasks ....... however these are typically *left over idle connections*
that did not get closed by the normal OSC.dispose() at the end of the
background task. Hence the motivation of this thread because I want to
create OSC, use it for a while, and then dispose of it ensuring no
residual connections, not because I have seen any memory problems,
because I haven't, but because I don't want to hit the max connections
limit variable on my database which, when I did one time last week,
caused a little bit of havoc for a few users.
So, rest assured, I am still only using one default OSC per instance
(not even using the ERXOSC pool) for regular requests and I am
creating short-lived OSC's for the frequent intense EOF editing/save
and I have not run out of memory in an instance in over a year, thanks
to ERXFetchSpecificationBatchIterator and in extreme cases,
ERXEOAccessUtilities.ChannelAction!
BTW, I do like the ConnectionBroker and it might be ideal for this app
to ensure connections are used efficiently, but in its current design,
if I am not mistaken, it appears to keep connections open forever once
opened, so it could do more harm than good in a peak user activity
situation.
Thanks for saying "it" Anjo! The good advice and genuine interest in
the success of others is one of the best things about this community :-)
Cheers, Kieran
On Nov 13, 2009, at 12:31 AM, Anjo Krank wrote:
Just to say it: I think 100 should not be used in production. Your
mem usage will go through the roof and your performance way down. 5
or so should be more like it.
Cheers, Anjo
Am 13.11.2009 um 00:14 schrieb Kieran Kelleher:
(I also set the <eomodelname>.DBMaxConnections = 100 since docs and
source seemed to differ, but I did not spend time figuring out if
only one of these or both worked.
_______________________________________________
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
_______________________________________________
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