ThreadLocal at the Service level ? I guess I'm being particularly jumpy today - I'm hacking powerpc assembler for a bootloader on a custom Freescale board and I wouldn't even touch that ;-) .
Cheers, Robert On 9/21/07, Hyma <[EMAIL PROTECTED]> wrote: > > As this is to track each request till the response and > does not have any relevance to the requestor, this > need not be part of the SOAP message. > > This can be achieved using ThreadLocal - every request > can be assigned a Unique generated ID that can be > stored in a Context assigned to the ThreadLocal. > > > > --- "Walker, Jeff" <[EMAIL PROTECTED]> wrote: > > > But can't each session can have multiple requests > > within it? (I'm > > thinking HTTP sessions here, is that not what you > > guys are thinking?) I > > think Ty said he wants unique ids on each request. > > > > On our project, we waited for WS-ReliableMessaging > > to come to web > > services (in WebSphere 6.1), that would give us > > unique ids for each > > request and response, sequencing of requests, > > repeated requests that > > were lost and requests out of order. Lots of good > > stuff. But we cannot > > wait any longer. > > > > I ended up coding a very primitive message id > > reflection technique. > > Client creates a SOAP header called MessageId. Add > > into it the UUID > > generated id from, as you say, Java5 (or .NET). The > > service receives the > > request and MessageID header, opens the header in a > > request handler > > class and stores it in the MessageContext for safe > > keeping until the > > response is ready. On the way out, a response > > handler class creates a > > MessageId SOAP header, containing, you guessed it, > > the messageId it gets > > from the MessageContext. > > 1. The client is solely responsible for uniqueness. > > 2. The service does not manipulate the messageId, > > just stores it. > > 3. Fault semantics are simple. No messageId > > available in request header > > -> Soap Fault. > > No messageId available when the response is being > > handled on the way > > out - > Soap Fault. > > 4. Any call that times out before a response is > > received, means > > obviously that the request was invalid, and a new > > messageId is generated > > by the client and the client tries that call again. > > 5. Such a primitive messageID reflection technique > > doesn't need a > > session to work. (Perhaps you need a session for > > something else, but not > > for this). > > 6. Recommend you add in 'To:' and 'From:' addressee > > fields to the > > MessageID header, as well as the messageId string > > field. > > 7. Recommend that you avoid anything more > > sophisticated like keeping > > track of previous messageIds received and sent. It > > gets nasty, very > > quickly. (Leave that to WS-ReliableMessaging, when > > it is ready for > > primetime). > > > > Hope this helps. > > -jeff > > > > > > > > > > > > -----Original Message----- > > From: robert lazarski > > [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 21, 2007 2:26 PM > > To: axis-user@ws.apache.org > > Subject: Re: Axis2 Request Tracking > > > > I often do session handling this way. What I do is > > on login, return a > > token generated by the UUID class in java 5 and > > later. Then I force > > the users on subsequent calls to pass in the token > > or the invokation > > is rejected. Works great if you can control policy > > on both sides. > > > > HTH, > > Robert > > > > On 9/21/07, tyju tiui <[EMAIL PROTECTED]> wrote: > > > > > > I guess I'll do this with the session though it > > seems wrong ... I > > can't > > > think of any other way to handle it. > > > > > > I'm still open to suggestions if anyone has a good > > idea to share :-) > > > > > > Thanks, > > > > > > Ty > > > > > > ----- Original Message ---- > > > From: tyju tiui <[EMAIL PROTECTED]> > > > To: axis-user@ws.apache.org > > > Sent: Friday, September 21, 2007 3:25:48 AM > > > Subject: Request Tracking > > > > > > > > > I'd like to assign a unique ID to each request as > > it comes in so that > > I > > > might track it all the way through to the outFlow. > > In other words I > > want to > > > give each request a tracking ID so I can go back > > in my logs and follow > > a > > > request's path all the way through my system. > > > > > > What do you guys and gals think the best way to do > > this might be? > > > > > > I've thought about doing something with a session > > variable, but that > > seems > > > to go against the stateless nature of WS in > > general. > > > > > > I also thought I might inject the unique ID into > > the request after > > I've > > > received it, but that also seems like a bad idea > > ... I'm sure there > > are a > > > million things that could potentially go wrong > > doing something like > > this. > > > > > > Your ideas are much appreciated. > > > > > > Thanks, > > > > > > Ty > > > > > > ________________________________ > > > Boardwalk for $500? In 2007? Ha! > > > Play Monopoly Here and Now (it's updated for > > today's economy) at > > Yahoo! > > > Games. > > > > > > ________________________________ > > > Don't let your dream ride pass you by. Make it a > > reality with Yahoo! > > Autos. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > ____________________________________________________________________________________ > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, > news, photos & more. > http://mobile.yahoo.com/go?refer=1GNXIC > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
