• 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: Snapshot problems - Solved, sort of
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Snapshot problems - Solved, sort of


  • Subject: Re: Snapshot problems - Solved, sort of
  • From: Chuck Hill <email@hidden>
  • Date: Sat, 21 Apr 2007 22:26:07 -0700


On Apr 21, 2007, at 5:51 PM, Steven Mark McCraw wrote:

Ok, so I turned off all the project wonder stuff (another 5 hours of work) and the thing keeps breaking. But I think I can rule out ERX* as the cause of the problem.

Good to know and thankfully not a big surprise.


I started looking way back on the list, and noticed that in early versions of WebObjects 5, tons of people (relatively speaking) where having the exact same problem I'm currently having. That is, when they were using nested editing contexts, they would often get messages and exceptions from EODatabase because of the (I think I've earned a rant here) poor, poor, pathetic job that EOF does of keeping track of the snapshots.

I won't deny that you have earned a rant or three. But unless you are using one of the early, buggy versions, EOF now does a flawless job of keeping track of snapshots. There were bugs before, and serious ones - no denying that - but now it is very solid and dependable.



I think that this has something to do with using nested editing contexts.

I have been wondering that myself.


I never once ran into the problem before I started using nested editing contexts (I was just creating EOs and not inserting them into an editing context, which worked fine), but after reading that this was one of the worst things I could do, changed all my code so that EOs immediately got inserted (there is now no instance of a EO constructor being called in my code. I use EOUtilities.createAndInsertInstance everywhere).

Are other people on the list creating EOs without inserting them into an editing context?

Yes, absolutely. They are the ones who write every few weeks with bizarre EOF problems that are keeping them at work late at night. This is mostly OK, most of the time. EOF is pretty robust. But when it breaks, it really, profoundly breaks. It just ain't worth it.



Are other people using nested editing contexts?

Yes, in reasonably heavily used production applications. BUT the big difference that I see is that you seem to create on per session. I usually create one per function/page.



If not, how do you keep things from getting stuck in the database half finished all over the place? Tons of local variables? And if so, is no one else seeing these kinds of ridiculous corrupted snapshot problems?

I tend to keep the session EC for long term, mostly read only objects. Edits get done in a peer EC local to the page(s) doing that specific edit. Each new editing action gets a new EC. If I need a child EC, that new EC gets its own child.



I finally found a workaround that works, taken from a post in like 2002. In Application's constructor, I call

EODatabase.disableSnapshotRefCounting();

HACK! :-)


Supposedly, this means that memory from every snapshot ever created of any object will just stick around in the database until the application dies (I say supposedly, because I can't find a shred of documentation from Apple that says exactly that, but posts from other people have implied as much. Am I starting to sound bitter?).

You are correct. And it will likely die from out of memory. That is why snapshot reference counting was implemented.



And if that is the case, it sucks to do it. The only thing that sucks worse is an application that breaks randomly and unpredictably everywhere I use a nested editing context. Is there some workaround to the workaround? That is, is there some way to periodically tell EODatabase to clean itself up so that it doesn't waste so much memory? Are people just scheduling monitor to restart their applications periodically?

Any thoughts?

You have something seriously bad in your application. I don't know what it is, yet. But there is something you are not telling us (not accusing you here, you undoubtedly are dismissing it as not relevant, I know that from personal experience). In my experience, EOF is very robust and dependable. As long as you don't mess with its head...


Chuck




On Apr 21, 2007, at 3:08 PM, Kieran Kelleher wrote:

AFAIK Project Wonder patches in ERXGenericRecord as a default entity class name for EOGenericRecord. Check this property in your Properties file
er.extensions.ERXEntityClassDescription.defaultClassName


Look at method
public void prepareEntityForRegistration(EOEntity eoentity)
in
ERXEntityClassDescription

On Apr 21, 2007, at 2:18 PM, Steven Mark McCraw wrote:

A) Why are my EOs getting cast to ERXGenericRecord still, and how do I make that stop so that I can see if it is in fact the problem



_______________________________________________
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: Snapshot problems - Solved, sort of
      • From: Steven Mark McCraw <email@hidden>
References: 
 >Re: Snapshot problems (From: Steven Mark McCraw <email@hidden>)
 >Re: Snapshot problems (From: Kieran Kelleher <email@hidden>)
 >Snapshot problems - Solved, sort of (From: Steven Mark McCraw <email@hidden>)

  • Prev by Date: Re: Snapshot problems - Solved, sort of
  • Next by Date: Re: Snapshot problems - Solved, sort of
  • Previous by thread: Re: Snapshot problems - Solved, sort of
  • Next by thread: Re: Snapshot problems - Solved, sort of
  • Index(es):
    • Date
    • Thread