• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: I'm killing my database
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I'm killing my database


  • Subject: Re: I'm killing my database
  • From: Chuck Hill <email@hidden>
  • Date: Tue, 24 Apr 2007 19:59:08 -0700

Hi Scott,

I would diagnose this as two problems:

1. Crud is building up in your EC making it slower

2. A FrontBase SQL parsing (guessing from experience) bug is causing the database process to crash.

Suggestions below.


On Apr 24, 2007, at 3:55 PM, Scott Winn wrote:

Hello Group,

I'm working on a flat file importer (groan).

It will never be a speed demon using EOF (it is just not optimized for that), but it can work well enough.



Creating EOs and writing to the database (Frontbase) seems to work fine. The objects I'm creating with the data have relationships like a tree structure with a single object (Certificate) at the top level followed by the next two tiers. There may be several hundred objects in the "tree", but 800 objects related to the top level Certificate would be enormous and extremely rare.

Sometimes my source data contains corrections. The most reliable way to handle them is to cascade delete the old objects and write new ones. There is nothing in my import correction data that tells me what has changed, so an edit seems pretty much out of the question. What I am finding is that EC.saveChanges after the delete tends to get slower the more of these I process. Eventually the database seems to hang-up; and by hang-up I mean, go to the DB management application and it says the database is stopped. I match certain data (dates, codes, etc) with the record I'm importing. If it matches I delete the one I have in the database before writing a new one. EC.deletedObjects just shows the one I am getting rid of. Here's the code. . .


// Cascade Delete Certificate to prepare for overwrite
System.out.println("Cascading Delete Certificate");
recordContext.deleteObject(importCertificate);
System.out.println("Updated Objects: " + recordContext.deletedObjects() + "\n");
System.out.println("Start Save: " + new NSTimestamp());
recordContext.saveChanges(); // <- Max 2 minutes, Min 5 sec, Avg 11 sec, longer times before crash

The first thing I would do is to add this line: recordContext .undoManager().removeAllActions();

The next thing I would do (voodoo or not) is to periodically dispose of recordContext and create a replacement. In the past that was vital. I think the bugs are fixed now, but I remain superstitious.


System.out.println("End Save: " + new NSTimestamp());


This is the first exception I got. By this point I had cascade deleted 234 EO groups. After this I got similar exceptions whenever I called anything from EOUtilities.

That is because the database process had died. Is there a newer version of FB that you can try? To hunt this down, you need to enable SQL logging on the database. The last statement logged before a crash should be what is causing the problem. There is probably something in your flat file that is giving FB heart attack. When you find it, let Geert and crew know. They are very good about fixing serious problems like this. No one likes a crashing database process.



Chuck



java.lang.IllegalStateException: _obtainOpenChannel -- com.webobjects.eoaccess.EODatabaseContext com.webobjects.eoaccess.EODatabaseContext@aa1384: failed to open database channel. Check your connection dictionary, and ensure your database is correctly configured.
at com.webobjects.eoaccess.EODatabaseContext._obtainOpenChannel (EODatabaseContext.java:2131)
at com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificati onEditingContext(EODatabaseContext.java:3204)
at com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecificatio n(EODatabaseContext.java:3355)
at com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsWithFetchSpec ification(EOObjectStoreCoordinator.java:539)
at com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecificatio n(EOEditingContext.java:4114)
at com.webobjects.eoaccess.EODatabaseContext.objectsForSourceGlobalID (EODatabaseContext.java:4260)
at com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsForSourceGlob alID(EOObjectStoreCoordinator.java:682)
at com.webobjects.eocontrol.EOEditingContext.objectsForSourceGlobalID (EOEditingContext.java:3965)
at com.webobjects.eoaccess.EODatabaseContext._fireArrayFault (EODatabaseContext.java:4427)
at com.webobjects.eoaccess.EOAccessArrayFaultHandler.completeInitializati onOfObject(EOAccessArrayFaultHandler.java:70)
at com.webobjects.eocontrol._EOCheapCopyMutableArray.willRead (_EOCheapCopyMutableArray.java:38)
at com.webobjects.eocontrol._EOCheapCopyMutableArray.count (_EOCheapCopyMutableArray.java:92)
at com.webobjects.eocontrol.EOClassDescription.propagateDeleteForObject (EOClassDescription.java:511)
at com.webobjects.eocontrol.EOCustomObject.propagateDeleteWithEditingCont ext(EOCustomObject.java:688)
at com.webobjects.eocontrol.EOClassDescription.propagateDeleteForObject (EOClassDescription.java:523)
at com.webobjects.eocontrol.EOCustomObject.propagateDeleteWithEditingCont ext(EOCustomObject.java:688)
at com.webobjects.eocontrol.EOEditingContext.propagateDeletesUsingTable (EOEditingContext.java:2231)
at com.webobjects.eocontrol.EOEditingContext._processDeletedObjects (EOEditingContext.java:2193)
at com.webobjects.eocontrol.EOEditingContext._processRecentChanges (EOEditingContext.java:1744)
at com.webobjects.eocontrol.EOEditingContext._prepareForPushChanges (EOEditingContext.java:3257)
at com.webobjects.eocontrol.EOEditingContext.saveChanges (EOEditingContext.java:3213)


// Save changes line above
at ImportProcess.ParseCertificate(ImportProcess.java:1080)
at ImportProcess.HandleRDT(ImportProcess.java:801)
at ImportProcess.HandleFileInput(ImportProcess.java:445)
at ImportProcess.performAction(ImportProcess.java:216)
at com.webobjects.woextensions.WOLongResponsePage.run (WOLongResponsePage.java:155)
at java.lang.Thread.run(Thread.java:613)



Seen anything similar? Am I going about this the wrong way? Deleting and entering a fresh copy seemed like the way to go. I could dispose of my EC periodically if it would help. It contains some NSDictionary values to help speed the look-up process, but I could dump the EC and re-build the dictionaries if I had to.


Thanks for any help offered,

Scott

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net


This email sent to email@hidden

--

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






_______________________________________________
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


  • Follow-Ups:
    • Re: I'm killing my database
      • From: Guido Neitzer <email@hidden>
    • java.lang.NoClassDeffoundError: Application
      • From: Jeff Schmitz <email@hidden>
References: 
 >I'm killing my database (From: Scott Winn <email@hidden>)

  • Prev by Date: Re: I'm killing my database
  • Next by Date: java.lang.NoClassDeffoundError: Application
  • Previous by thread: Re: I'm killing my database
  • Next by thread: java.lang.NoClassDeffoundError: Application
  • Index(es):
    • Date
    • Thread