OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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]