sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-j] AW: ISSUE 8: Concurrency model for Service Reference instances
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Java" <sca-j@lists.oasis-open.org>
- Date: Sun, 24 Feb 2008 14:11:10 +0000
Michael,
Yes, precisely.
Not a design that I like much.
I'm working up a different way of looking
at callback that is a lot more radical......
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>
22/02/2008 17:25
|
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 |
|
Mike,
In case (1) below, are you
imagining that the ServiceReference object would be shared between threads,
but that the callbackID would be thread local?
Michael
From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Friday, February 22, 2008 9:31 AM
To: OASIS Java
Subject: Re: [sca-j] AW: ISSUE 8: Concurrency model for Service Reference
instances
Folks,
I said in a previous note that I'd get around to the question of Callbacks.
This note deals with the Callbacks.
Callbacks are different from conversations today. (Yes, I realize
that there are proposals to change this)
The principal difference is the need for a client to be able to distinguish
each invocation it makes on an
operation of a service reference. ie logically, the client needs
to impose a callback ID on each invocation
of the reference and be able to access this callbackID when it receives
an invocation on the callback
interface.
This clearly gives a problem if multiple threads are allowed to make forward
calls on the service reference
object held by the client. There is a time window between setting
the callbackID and invoking the reference
method - and this allows one thread to potentially interfere with another.
There seem to be two approaches to this:
1) Have the callbackID set as a thread local variable.
2) Change the design of callback interfaces so that there is a version
of each operation which includes the
callbackID as an additional parameter on each method, allowing the client
to set the callbackID directly onto
each invocation. The precedent for this approach is the existing
JAX-WS approach to the asynchronous client
API, which is generated by formula from the standard call-and-return API
for a service.
Either of these approaches means that any given forward request can have
a correct callbackID available on
a per-invocation basis to the binding code that packages the request for
tranmisssion form the client to the
service.
Problem solved.
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
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]