RE: [sca-j] AW: ISSUE 8: Concurrency model for Service Reference instances

[Mike Edwards <mike_edwards@uk.ibm.com>]

Michael,

OK, let's declare a truce on the code
front  ;-)

I agree that this needs no changes in
the spec.

I'd still like to ask why we need to
keep setConversationID()?  Is there really that much useful function
associated with it?

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

"Michael Rowley" <mrowley@bea.com>

27/02/2008 13:38

To	Mike Edwards/UK/IBM@IBMGB, "OASIS Java" <sca-j@lists.oasis-open.org>
cc
Subject	RE: [sca-j] AW: ISSUE 8: Concurrency model for Service Reference instances

You are absolutely right about
the race condition in my code.  And yes, getting code to be thread
safe while also allowing some concurrency is far from trivial.
 
Nonetheless, nothing we are
suggesting requires anything new from the spec.  If the developer
wanted to keep things simple, the entire buyBook routine would just be
synchronized, the developer would gain simplicity at the cost of some concurrency.
 I’m not sure we need to get rid of setConversationID() as a means
to improve concurrent programming scenarios.
 
Michael

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU