• 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: Concurrent request handling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrent request handling


  • Subject: Re: Concurrent request handling
  • From: Chuck Hill <email@hidden>
  • Date: Tue, 05 Apr 2011 10:48:10 -0700

Hi Mark,

On Apr 4, 2011, at 11:20 PM, Mark Wardle wrote:

> Hi all,
>
> There have been a number of threads discussing this runtime option. I
> think the consensus opinion was that although it is off by default, it
> is better switched on.

I think it is off by default to match the previous (now ancient) functionality.


> Presumably there are some basic additional rules to follow.

The EOF Commandments (as usual) plus:

Don't Do Stupid Things



> For instance, AFAIK components will not be shared by multiple threads
> as they will be instantiated as one goes along or will be returned
> from the page cache as part of a single session - and as one session
> will be handled by only one thread, this is fine. How does concurrent
> handling interact with stateful and stateless components?

Stateful are always session specific so safe by design.  Stateless are also safe, transparently, see Practical WebObjects for the details if you want.


> Perhaps more of an issue is that code within my EOF classes may be
> executed by more than one thread at a time. I use lazy initialisation
> but there is a race condition there. Fortunately, most of the time
> there are no side-effects and running that code twice would have no
> significant deleterious effect. For situations where it would matter I
> would assume protecting lazy initialisation with a double check and a
> synchronised block for the inner check would be fine? Is that
> interpretation correct?

I think that synchronised is what you want.


> Are there other commandments?


Don't Do Stupid Things  :-)  Which boils down to don't share objects that are not thread-safe, or writable data, at the global level unless you have appropriate protection.  Global being either static members or instance variables on your application.  Shared, non-thread safe formatters are a common mistake.


Chuck


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

  • Follow-Ups:
    • Re: Concurrent request handling
      • From: Mark Wardle <email@hidden>
    • Re: Concurrent request handling
      • From: Matteo Centro <email@hidden>
References: 
 >Concurrent request handling (From: Mark Wardle <email@hidden>)

  • Prev by Date: ERXObjectStoreCoordinatorPool, setting maxCoordinators higher than 1 result in unreliable synchronization
  • Next by Date: Re: Concurrent request handling
  • Previous by thread: Concurrent request handling
  • Next by thread: Re: Concurrent request handling
  • Index(es):
    • Date
    • Thread