I don't like either of these options.
A simpler solution is to not attempt to share service references
between asynchronously executing requests that need to set a callback ID.
I'd prefer to eliminate setCallbackID() altogether but that's for
discussion as part of another issue.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
Mike Edwards/UK/IBM@IBMGB
24/02/2008 14:11
To
"OASIS Java" <>
cc
Subject
RE: [sca-j] AW: ISSUE 8: Concurrency
model for Service Reference instances
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:
"Michael Rowley"
<>
22/02/2008 17:25
To
Mike Edwards/UK/IBM@IBMGB,
"OASIS Java" <>
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:]
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:
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
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
