• 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: IllegalStateException in _beginTransaction()
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IllegalStateException in _beginTransaction()


  • Subject: Re: IllegalStateException in _beginTransaction()
  • From: Chuck Hill <email@hidden>
  • Date: Mon, 28 Feb 2011 21:46:39 -0800

Hi Paul,


On Feb 28, 2011, at 9:38 PM, Paul Hoadley wrote:

> Hi Chuck,
>
> On 01/03/2011, at 3:32 PM, Chuck Hill wrote:
>
>> On Feb 28, 2011, at 8:51 PM, Paul Hoadley wrote:
>>
>>> On 01/03/2011, at 4:38 AM, Chuck Hill wrote:
>>>
>>>> It is possible  that some prior transaction had an error and left the DBC transaction open?
>>>
>>> Actually, yes, I think I can see a couple of candidates.  A user can initiate a long-running background task from the page in question, which does touch EOF to create some data for download relating to a chosen EO.  (I'm reasonably sure those background tasks are well-behaved, in that they use their own ERXEC to do their work, and the EO is passed in using its EOGlobalID.)
>>
>> Do you create an EOF stack for these long running tasks?    I would suggest doing that.
>
> I'm not currently, but I'll change it to do so.  Tell me, is the difference between just doing ERXEC.newEditingContext(new EOObjectStoreCoordinator()) and using an OSC pool approach just that the latter ensures an upper limit on how many stacks the app creates?  Or are there significant setup/teardown costs involved in the former every time a user starts a background task?  (Or both?)

IIRC, they don't get torn down.  Or not easily.  Pools are much better unless you create one and use it for the lifetime of the app.


>>> 2.  I've been tuning the RAM available to the instance, and sometimes it runs short.  Just after the IllegalStateException (which presumably rules it out as a cause) there's an OutOfMemoryError when the JVM ran out of heap space.
>>>
>>> Are either of these potential causes?
>>
>> Yes!  Run out of memory and all bets are off.    All kinds of things can happen in this case, the JVM is often insane.  Likely the IllegalStateException resulted from running out of memory.
>>
>> Where possible (sometimes it can't recover enough memory to even properly throw the exception) I try to catch this in the Application's handleException and then System.getRuntime.exit(1)
>
> Thanks.  So the fact that the OutOfMemoryError was logged _after_ the IllegalStateException doesn't preclude it from being the cause?


No.  All.  Bets.  Off.   :-)


--
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







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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

References: 
 >IllegalStateException in _beginTransaction() (From: Paul Hoadley <email@hidden>)
 >Re: IllegalStateException in _beginTransaction() (From: Chuck Hill <email@hidden>)
 >Re: IllegalStateException in _beginTransaction() (From: Paul Hoadley <email@hidden>)
 >Re: IllegalStateException in _beginTransaction() (From: Chuck Hill <email@hidden>)
 >Re: IllegalStateException in _beginTransaction() (From: Paul Hoadley <email@hidden>)

  • Prev by Date: Re: IllegalStateException in _beginTransaction()
  • Next by Date: Issue With the Eclipse
  • Previous by thread: Re: IllegalStateException in _beginTransaction()
  • Next by thread: Programmatically changing database configuration on startup
  • Index(es):
    • Date
    • Thread