• 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: Back To Basics : Databases Active Editing Context
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Back To Basics : Databases Active Editing Context


  • Subject: Re: Back To Basics : Databases Active Editing Context
  • From: Chuck Hill <email@hidden>
  • Date: Mon, 7 Jul 2008 09:52:48 -0700


On Jul 6, 2008, at 6:49 PM, Owen McKerrow wrote:

OK so we think we probably screwed up implementing MultiLockManager somehow, so heres a couple of more questions to make sure all of our bases are covered :

In Session's sleep we have ( terminate looks exactly the same except of course its for terminate )

public void sleep()

      try {
			synchronized (ecLockManager) {
				if (ecLockManager().isLocked()) {
					ecLockManager().unlock();
				}
			}
	   }
		finally {
			super.sleep();
		}
	}

This is from my WOSession sub-class (very old code that I have not touched in years):


public void awake()
{
try
{
ecLockManager().lock();
}
catch(Throwable t)
{
NSLog.err.appendln("********** EXCEPTION in WOSession.awake() calling ecLockManager.lock(): " + t);
}
super.awake();
}



public void sleep()
{
// Need to check as this gets called after terminate() when logging out
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
try
{
ecLockManager().unlock();
}
catch (Throwable t)
{
NSLog.err.appendln("********** EXCEPTION in WOSession.sleep() calling ecLockManager.unlock(): " + t);
}
}
}


        super.sleep();
    }


public void terminate()
{
// Need to make sure this is unlocked so that editing contexts nested in the defaultEditingContext
// don't hold locks on it when it gets disposed
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
try
{
ecLockManager().unlock();
}
catch (Throwable t)
{
NSLog.err.appendln("********** EXCEPTION in WOSession.terminate() calling ecLockManager.unlock(): " + t);
}
}
}


        super.terminate();
    }


Your implementation looks fine to me.



Should we be using unregisterEditingContext instead of unlock() ? If not why/when should you use unregisterEditingContext ?

I very rarely use it. I think I used it once where it was possible that two ECs had been created where I only needed one. This was used to quickly discard the one that was not needed.



Chuck


On 04/07/2008, at 3:53 PM, Lachlan Deck wrote:

On 04/07/2008, at 2:54 PM, Chuck Hill wrote:

On Jul 3, 2008, at 9:30 PM, Lachlan Deck wrote:

Perhaps a parent ec? Is there any child ecs involved here?

I don't recall terribly clearly now as it's been a while... but I remember that for some strange reason an object that I had in the shared editing context didn't localize into the ec that I wanted when attempting to set the relationship - but there was no exception until saveChanges. It might have been when said ec didn't have its sharedEc == null, or invalid locking or something.

I recall, when trying to track it down, mucking around with temporarily unlocking shared ec locks and stuff. But I think it turned out to be ensuring that the ec in question didn't properly set its shared ec to null (I think).

Sorry I don't recall much more than that.

Ah, there you go on about the shared EC again. :-P

Someone says it can't/shouldn't be used... just can't help myself... Shared ec, VI, ... I'm just waiting for the next suggestion :-)


I had not considered the SEC being involved. That puts a new twist on things.

Owen, are you using the SEC?

Bear in mind that you *might* be using it unintentionally. e.g., you've declared in your model 'share objects' and/or you're not nullifying your ec's shared ec (which is the usual for your default session context IIRC).


with regards,
--

Lachlan Deck

_______________________________________________
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



--

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


References: 
 >Back To Basics : Databases Active Editing Context (From: Owen McKerrow <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Chuck Hill <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Owen McKerrow <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Chuck Hill <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: "M.Y. Tjoe" <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Chuck Hill <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Lachlan Deck <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Chuck Hill <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Lachlan Deck <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Chuck Hill <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Lachlan Deck <email@hidden>)
 >Re: Back To Basics : Databases Active Editing Context (From: Owen McKerrow <email@hidden>)

  • Prev by Date: Re: [ANN] WO 5.4.2 javadoc tarball
  • Next by Date: Re: EOFetchSpecification text to number conversion
  • Previous by thread: Re: Back To Basics : Databases Active Editing Context
  • Next by thread: ERXLocalizer getting rid of the binding errors?
  • Index(es):
    • Date
    • Thread