• 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: locking problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: locking problem


  • Subject: Re: locking problem
  • From: David Teran <email@hidden>
  • Date: Tue, 21 Dec 2004 00:15:17 +0100

Hi,

OK, the locking stuff is not so complicated:

1) surround every lock unlock by a try finally statement if it occurs in one method:

try {
 ec.lock();
 ... some code ...
} finally {
 ec.unlock();
}

This is important because ...some code... might raise an exception and then the unlock() would be missing.


2) Keep in mind that resolving a fault might occur during appendToResponse, this can happen for the following example:



try { ec.lock(); users = EOUtilities.objectsForEntityNamed(ec, "Users"); } finally { ec.unlock(); }

now if users is bound to a WORepetition's 'list' binding the the users will be fetched during appendToResponse if they were a) never fetched b) if they were fetched but the timestamplag from the ec is newer than the one from the snapshot

so in this case the code above would result in EOF usage -without- a lock, bad thing.

The only solution is to lock and unlock the ec, but when?

1) as above and additionally in appendToResponse:

public void appendToResponse(WOResponse r, WOContext c) {
 try {
 ec.lock();
 super.appendToResponse(r, c);
 } finally {
 ec.unlock();
 }
}

i cannot really recommend this, but it works in most cases.

2) using ERXEC from project wonder: this nice editingcontext factory does all you need.

3) locking on creation or in session's awake, unlocking in session's sleep method. This is more or less what the multilockmanager does.

regards, David
 On 19.12.2004, at 23:50, Nathan Dumar wrote:



In reading a discussion thread about ERXEC recently, Anjo said that ERXEC only locks during the "dangerous" operations, like save, fetch, etc. So, that's what I'm doing now -- putting locks in the try block, before any fetch or save, and unlocking right after, in the finally block. From what I've read, this seems to be the best solution, but I'm always open to learn more. If anyone has suggestions, ideas, warnings, or whatever, please post.


_______________________________________________
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: 
 >locking problem (From: Nathan Dumar <email@hidden>)
 >Re: locking problem (From: Ben Trumbull <email@hidden>)
 >Re: locking problem (From: Nathan Dumar <email@hidden>)
 >Re: locking problem (From: Nathan Dumar <email@hidden>)
 >Re: locking problem (From: Ben Trumbull <email@hidden>)
 >Re: locking problem (From: Nathan Dumar <email@hidden>)

  • Prev by Date: Re: Download via Componnt with IE SP2 and SSL
  • Next by Date: How to create a d2w Rule from java
  • Previous by thread: Re: locking problem
  • Next by thread: Setting the statuscode for the response in a directAction
  • Index(es):
    • Date
    • Thread