Okay, more questions, and sorry if the terminology is wrong; I'm a programmer in job title only.
Suppose my web service is request scoped. Axis makes a new instance of my web service class to handle each request, right? And each request gets its own thread? So if it's application scoped, then every time Axis gets a request, it'll call the appropriate method in the one shared instance of my class... And that's where the synchronize()ing comes in. This I (sort of) get, though I've never had to write a thread-safe program. This means, though, that I can have an "entry point" that is synchronize()d and whose sole purpose is to hook requests up with their session, and then each session can have its own instance of an object that does the real processing. And I can process two, or ten, or fifty requests all at once, and the most any request will have to wait for is for the session lookup method to come free. Again, forgive the quasi-technical lingo. Andrew At 05:55 PM 4/19/2002 -0300, you wrote: >The only problem with that is synchronize()ing the object as it would have >global scope. >----- Original Message ----- >From: "Andrew Vardeman" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, April 19, 2002 5:38 PM >Subject: RE: how to implement sessions, persistent objects, etc. ? > > > > Lene, Stan and Glen, > > > > thanks for the tips. > > > > Unfortunately, the client won't be using Axis so I can't do things the >easy > > way; we're developing on the .NET desktop platform and assuming it will > > port easily to a CE device when our organization buys new handhelds (has > > been using Apple Newtons since 1997). > > > > So, do I understand correctly that I can declare my service to have > > application scope, and then its member variables persist to the next > > request? That way I could build a hashtable of session IDs and objects > > that hold session data (I'm primarily interested in keeping a database > > handle open for transactions spanning multiple messages) and hook up each > > request from the .NET client with its session data based on a session ID >it > > would send as a SOAP header or something. > > > > Andrew > > > > At 03:32 PM 4/19/2002 -0400, you wrote: > > > > >Hi Andrew! > > > > > >Sessions are easy if you're using Axis on both sides - if not you have to > > >make sure that your non-Axis client can send the right cookies/SOAP > > >headers to use them. Then you set your service to be session-enabled: > > > > > ><service name="whatever" provider="java:RPC"> > > > <parameter name="scope" value="session"/> > > > ... > > ></service> > > > > > >The other issue, asynchronous callbacks, is more interesting, but isn't > > >something we support yet. You'd essentially need the abiliity to have > > >Axis spawn off worker threads to handle asynchronous or process-based > > >backends. Doable, but not for this release. > > > > > >--Glen > > > > > > > -----Original Message----- > > > > From: Andrew Vardeman [mailto:[EMAIL PROTECTED]] > > > > Sent: Friday, April 19, 2002 2:45 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: how to implement sessions, persistent objects, etc. ? > > > > > > > > > > > > Hi folks. > > > > > > > > My supervisor and I are hoping to use SOAP for communications > > > > between a > > > > handheld data collection instrument and the server where the data are > > > > stored. For this we need a dialogue between the handheld and > > > > the server > > > > that will last for more than one request/response. If I > > > > understand Axis > > > > properly, each request is an island. How do I persist > > > > session data? Or, > > > > suppose I want the server to send two messages for every one > > > > sent by the > > > > client. Or, say I want to fire off an arbitrary number of > > > > status messages > > > > as I process the client's request. Is there any way (other > > > > than writing a > > > > separate program and having Axis communicate with it, which > > > > seems to defeat > > > > the whole purpose of Axis) to keep a process running that is > > > > specific to > > > > one client's session? Is it possible for the server to send > > > > "responses" > > > > without the associated requests? > > > > > > > > Does that make any sense? > > > > > > > > Andrew > > > > > > > > > > > > > >
