Interesting patch
On Wednesday 30 January 2008, Tully, Gary wrote: > RequestContexts are thread local but the proxy also maintains a map. > On a call to > getRequestContext() the thread local is initialized from the proxy > map. Any mods made to the thread local are echoed to the proxy map but > on an invocation, the thread local contexts are used. In this way, > threads have safe access to their context between calls to > getRequestContexts(). Interesting solution. Basically, if a client does: Map ctx = bp.getRequestContext(); ctx.put(...); ctx.put(...); ctx.put(...); Things would be guaranteed safe. However, if they do: bp.getRequestContext().put(....); bp.getRequestContext().put(....); bp.getRequestContext().put(....); it wouldn't be. I'm actually OK with that. Very creative. Dan >On Wednesday 30 January 2008, Tully, Gary wrote: > Hi Dan, > I have submitted a patch via > https://issues.apache.org/jira/browse/CXF-1410 > > RequestContexts are thread local but the proxy also maintains a map. > On a call to > getRequestContext() the thread local is initialized from the proxy > map. Any mods made to the thread local are echoed to the proxy map but > on an invocation, the thread local contexts are used. In this way, > threads have safe access to their context between calls to > getRequestContexts(). > > There is some more detail in the jira. > > Gary. > > > -----Original Message----- > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > Sent: 23 January 2008 20:29 > > To: [email protected] > > Cc: Tully, Gary > > Subject: Re: JAXWS proxy thread safety 'with' requestContext > > > > > > Gary, > > > > I guess I would need more details about your proposed > > solution. ( a patch would be nice) > > > > I guess what you are describing is basically something like a > > two stage Map of somesort where the "parent" map is in the > > proxy and the child is > > in the thread local. All writes would go to both. All > > "gets" would > > go child first, then parent if not found. Likewise > > iterators would do > > child first, the parent for values not in the child. Is that about > > correct? > > > > That probably would work fine. I'd definitely ask Jarek to > > run the full Geronimo suite with it before finallizing it though. > > > > There would definitely still be some funkyness to it though. > > If one thread DOESN'T set the ENDPOINT_ADDRESS and another > > does, the first > > thread would get it. Likewise for other things in the context like > > Headers and and such. > > > > I honestly think it might be best to just go with a proprietary > > getThreadLocalRequestContext() or something. Definitely > > would make > > it such that the standard JAX-WS API's would remain portable > > to other implementations. > > > > Dan > > > > On Wednesday 23 January 2008, Tully, Gary wrote: > > > The current state is that a proxy is thread safe provided you > > > don't use context parameters. If you do, all thread safety bets > > > are off. > > > > > > I would like to see a scenario where a CXF jaxws proxy can > > > > be thread > > > > > safe. Either through a config option which makes contexts > > > > threadLocal > > > > > or through an non-standard api like > > > proxy.getThreadLocalRequestContext() or through some other code > > > change, there is a proposal at the end. > > > > > > I want to determine if this is feasible or if there are some other > > > blockers. > > > > > > There has been a bunch of discussion[2][3][4][5] about this in the > > > past and CXF has evolved from a case where request/Reply > > > > Contexts were > > > > > threadLocal[1][2] to the current state where replyContexts > > > > are thread > > > > > local and requestContexts are per proxy and are copied before an > > > invocation. The endpoint address is also reset after an > > > > invocation, in > > > > > the event that one of the handlers changes it [3]. > > > > > > The end result is that the CXF Clientimpl and JAXWS proxy that > > > sits over it are not thread safe. > > > > > > It is currently not possible to have two threads > > > > predictably use the > > > > > same proxy and do: > > > > > > Greeter g = getCachedGreeterProxy(...) URL url = chooseUrl(...); > > > (javax.xml.ws.BindingProvider g). > > > getRequestContext(). > > > put(javax.xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY, > > > url); g.greetMe("foo"); > > > > > > Granted, the spec is a little vague[6][3] but I think the above is > > > valuable as proxy creation is fairly heavy weight. > > > > > > There are two use cases that seem to be instrumental in the > > > current implementation: > > > > > > 1) Having a requestContext property persist past a single > > > > invocation. > > > > > 2) Having one thread create and use a proxy, setting > > > requestContext values etc and having another thread use the same > > > proxy as > > > > is, but see > > > > > the requestContext properties set by the creator. > > > > > > I am thinking that a hybrid approach, where the contexts are > > > threadLocal, take precedence for the current request and > > > > are persisted > > > > > to the proxy, is the best approach. > > > > > > 1) will work, 2) will work and 3) multiple threads that > > > > 'always' set > > > > > their own request context properties will work. > > > > > > > > > Are there more use cases and have I captured the current state of > > > play? Is the concept of a thread safe proxy achievable at all? Is > > > there other per request state managed by the proxy, attachments > > > etc. [6]? > > > > > > Please advise? > > > > > > Thanks, > > > Gary. > > > > > > Some of the previous threads: > > > > > > [1] https://issues.apache.org/jira/browse/CXF-470 > > > [2] > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00150.h > >tm > > > > >l [3] > > > > http://www.mail-archive.com/[email protected]/msg02914.ht > >ml > > > > > [4] https://issues.apache.org/jira/browse/CXF-414 > > > [5] > > > > http://markmail.org/message/q2tx7ofm3lpqzjd6#query:+page:1+mid:vpwun > >7x > > > > >xi 4r67ocv+state:results > > > [6] > > > > http://lists.jboss.org/pipermail/jbossws-dev/2007-December/001096.ht > >ml > > > > > ---------------------------- > > > IONA Technologies PLC (registered in Ireland) Registered Number: > > > 171387 Registered Address: The IONA Building, Shelbourne > > > > Road, Dublin > > > > > 4, Ireland > > > > -- > > J. Daniel Kulp > > Principal Engineer, IONA > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, > Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
