Re: [Wonder-disc] ERXEC EOEditingContext in background thread

[Jeff S. <jef...@ma...>]

No no, I'd like to get to the bottom of things if it looks funny to  
you.  Let me try to go back to keeping the same object store and EC  
and see what happens.

Thanks!
Jeff


On Mar 9, 2009, at 2:29 PM, Chuck Hill wrote:

>
> On Mar 8, 2009, at 9:55 PM, Jeff Schmitz wrote:
>> On Mar 8, 2009, at 11:44 PM, Chuck Hill wrote:
>>> On Mar 8, 2009, at 1:55 PM, Jeff Schmitz wrote:
>>>
>>>> And yes, you are right, the EOObjectStore dispose is not closing  
>>>> the connections.
>>>
>>> I still find it very, very suspicious that  you need to create a  
>>> new OSC to handle memory and performance problems.  I suspect  
>>> that  something else is afoot.
>>>
>> Actually, I don't as far as performance goes anymore (prefetching  
>> helped in that respect).  BUT it does reduce the memory footprint,  
>> which is really the only reason I'm doing it now.  If nothing else,  
>> it helps when I'm running on the development machine so I can do  
>> other things.  Without it all my other programs get paged out.
>
> I've never seen this necessary to reduce the memory footprint for  
> long running, data intensive processes.  That you do need to do this  
> suggests that you have an issue elsewhere that this is masking.  But  
> if it works for you...
>
>
> Chuck
>
>
>
>>>>
>>>> When I run the first fetch on a new EOObjectStoreCoordinator:
>>>>
>>>> Pool pool = (Pool)  
>>>> ec.objectsWithFetchSpecification(poolFetch).lastObject();
>>>>
>>>> two new connections are created.  I can get rid of one of the  
>>>> connections by running the following before the dispose:
>>>>
>>>> EOFetchSpecification osFetchSpec = new  
>>>> EOFetchSpecification(Pool.ENTITY_NAME, null, null);
>>>> EODatabaseContext databaseContext =  
>>>> (EODatabaseContext 
>>>> )resultsObjectStore.objectStoreForFetchSpecification(osFetchSpec);
>>>> NSArray <EODatabaseChannel> channels =  
>>>> databaseContext.registeredChannels();
>>>> Iterator <EODatabaseChannel> channelIter = channels.iterator();
>>>> 		
>>>> while (channelIter.hasNext()) {
>>>>    EODatabaseChannel channel = channelIter.next();
>>>>    channel.adaptorChannel().closeChannel();
>>>> }
>>>> resultsObjectStore.dispose();
>>>>
>>>> but I don't know how I might get a hold of the other one to close  
>>>> it.  Any ideas?
>>>>
>>>> Thanks!
>>>> Jeff
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 7, 2009, at 11:49 PM, Chuck Hill wrote:
>>>>
>>>>>
>>>>> On Mar 7, 2009, at 8:26 PM, Jeff Schmitz wrote:
>>>>>
>>>>>> It locked up again, but I have another clue.
>>>>>
>>>>> Knowledge is power.
>>>>> http://www.gvcsitemaker.com/gvc.webobjects/faq&mode=single&recordID=41413
>>>>>
>>>>>
>>>>>> Frontbase is outputting the following error message every 10  
>>>>>> seconds.
>>>>>>
>>>>>> 2009-03-07 22:17:28 [13295] fssAccept: Accept failed (24): Too  
>>>>>> many open files
>>>>>>
>>>>>> Also, the current state of the thread in top:
>>>>>> PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD   
>>>>>> RSIZE  VSIZE
>>>>>> 19408 java                    0.1%  0:12.66  29   820            
>>>>>> 261       35M-          22M    48M-  278M-
>>>>>>
>>>>>> Apparently I'm not closing something somewhere?
>>>>>
>>>>> I'd guess that osc.dispose() leaves the database connection  
>>>>> intact.
>>>>>
>>>>>
>>>>> Chuck
>>>>>
>>>>>
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>> On Mar 7, 2009, at 8:03 PM, Kieran Kelleher wrote:
>>>>>>
>>>>>>> IIRC, you have to do your own lock/unlock in regular  
>>>>>>> background threads ..... I always do  anyway .....
>>>>>>>
>>>>>>> ec.lock();
>>>>>>> try {
>>>>>>> 	//do stuff
>>>>>>> } catch (Exception e) {
>>>>>>> 	// handle
>>>>>>> } finally {
>>>>>>> 	ec.unlock();
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mar 7, 2009, at 8:04 PM, Jeff Schmitz wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> Below is my setup for executing a background thread with its  
>>>>>>>> own EOObjectStoreCoordinator and its own EOEdtingContext.   
>>>>>>>> Note that I'm using ERXEC to create the EOEditingContext, and  
>>>>>>>> have the below properties set.  Also note that I don't do  
>>>>>>>> lock or unlock as I understand that ERXEC does this for you.   
>>>>>>>> Is this correct?  Is it ok to use this in a thread?  The  
>>>>>>>> reason I ask is that I can kick off the thread and not touch  
>>>>>>>> my app in any other way, and more often than not the  
>>>>>>>> calculations will hang after about 15 minutes as if its  
>>>>>>>> deadlocked.  However I haven't been able to repeat the error  
>>>>>>>> with lock logging on yet.  Could it have something to do with  
>>>>>>>> the Session timing out during processing?  Or is there  
>>>>>>>> something else I don't have quite right?
>>>>>>>>
>>>>>>>> er.extensions.ERXApplication.useEditingContextUnlocker=true
>>>>>>>> er.extensions.ERXEC.defaultAutomaticLockUnlock=true
>>>>>>>> er.extensions.ERXEC.useSharedEditingContext=false
>>>>>>>> er.extensions.ERXEC.defaultCoalesceAutoLocks=true
>>>>>>>> er 
>>>>>>>> .extensions 
>>>>>>>> .ERXEnterpriseObject.applyRestrictingQualifierOnInsert=true
>>>>>>>> er 
>>>>>>>> .extensions.ERXEnterpriseObject.updateInverseRelationships=true
>>>>>>>>
>>>>>>>> public static void updateResults() {
>>>>>>>>
>>>>>>>> //Do lots of loops
>>>>>>>> while (...) {
>>>>>>>> resultsObjectStore = new EOObjectStoreCoordinator();
>>>>>>>> resultsEC = ERXEC.newEditingContext(resultsObjectStore);
>>>>>>>>
>>>>>>>> //Do lots of processing.
>>>>>>>>
>>>>>>>> resultsEC.saveChanges();
>>>>>>>>
>>>>>>>> //Free up the memory, nothing will be reused in next loop  
>>>>>>>> anyway.
>>>>>>>> resultsEC.dispose();
>>>>>>>> resultsObjectStore.dispose();
>>>>>>>> resultsObjectStore = new EOObjectStoreCoordinator();
>>>>>>>> resultsEC = ERXEC.newEditingContext(resultsObjectStore);
>>>>>>>>
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> public static void updateResultsThread() {
>>>>>>>> t = new Thread("updateResults") {
>>>>>>>>   public void run() {
>>>>>>>>      updateResults();
>>>>>>>>   }
>>>>>>>> };
>>>>>>>> t.start();
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Jeff
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list      (Web...@li... 
>>>>>>>> )
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
>>>>>>>>
>>>>>>>> This email sent to kie...@ma...
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San  
>>>>>> Francisco, CA
>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing  
>>>>>> the Enterprise
>>>>>> -Strategies to boost innovation and cut costs with open source  
>>>>>> participation
>>>>>> -Receive a $600 discount off the registration fee with the  
>>>>>> source code: SFAD
>>>>>> http://p.sf.net/sfu/XcvMzF8H_______________________________________________
>>>>>> Wonder-disc mailing list
>>>>>> Won...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/wonder-disc
>>>>>
>>>>> -- 
>>>>> Chuck Hill             Senior Consultant / VP Development
>>>>>
>>>>> Practical WebObjects - for developers who want to increase their  
>>>>> overall knowledge of WebObjects or who are trying to solve  
>>>>> specific problems.
>>>>> http://www.global-village.net/products/practical_webobjects
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> -- 
>>> Chuck Hill             Senior Consultant / VP Development
>>>
>>> Practical WebObjects - for developers who want to increase their  
>>> overall knowledge of WebObjects or who are trying to solve  
>>> specific problems.
>>> http://www.global-village.net/products/practical_webobjects
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> -- 
> Chuck Hill             Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their  
> overall knowledge of WebObjects or who are trying to solve specific  
> problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
>