users@jax-rpc.java.net

RE: SLSB instance will be created as needed, what about JAX-RPC servlet instance?

From: Anne Thomas Manes <anne_at_manes.net>
Date: Mon, 2 Aug 2004 17:54:39 -0400

It depends on the JAX-RPC runtime you're using.

See Section 10.1.1 for a description of the service endpoint lifecycle.

Most JAX-RPC implementations support instance pooling. Most implementations
also support configurable application scope -- one per request, one per
session, or a singleton for all requests.

Anne

-----Original Message-----
From: Merten Schumann [mailto:Merten.Schumann_at_asg.com]
Sent: Friday, July 30, 2004 9:21 AM
To: users_at_jax-rpc.dev.java.net
Subject: SLSB instance will be created as needed, what about JAX-RPC servlet
instance?

Hello,

AFAIK for a web service implemented with stateless session bean
technology the app server creates a new SLSB instance if at a time
there's no free instance for an incoming request.

How are things when the web service is implemented in (JAX-RPC) servlet
technology? Will there be only one instance of the servlet created by
the app server?

If answer is "yes", will this one and only instance be called by
mutliple threads at a time to serve a number of clients or will there be
a queue or so?

If answer is "no" - that means if there are multiple servlet instances
created similar to that SLSB stuff - could they be in a clustered
environment live on different hosts, as with EJB stuff? I guess (and
hope for some reason), they cannot be "clustered".

Thank you!
   Merten

P.S. Just to mention: I do ask this question since I think I'm running
in a situation where I cannot use EJB (J2EE) stuff to implement my web
service. The problem is, I have to deal with synchronized statements and
non-serializable data (connections to a server, that means sockets ...).
Further I would like to maintain some client state over a period of
time. For example, I have to store, per client, such connections and
some data depending on exactly one of the connections and so on. I got
the impression that for this kind of stuff good old servlet technology
is better to use since I could use there static variables (in the one
and only JVM) to maintain client state. But I have to admit I'm a J2EE
newbie :-(

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net