> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Craig
> R. McClanahan
> Sent: Friday, September 10, 1999 1:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: 2.2 Spec and number of Instances
>
>
> Randy Belknap wrote:
>
> > "Craig R. McClanahan" wrote:
> > > For example, consider a simple hit counting servlet. The natural place to
> > > store the counter would be an instance variable in the servlet
> class (suitably
> > > initialized in the init() method and saved to disk in the
> destroy() method).
> > > But, if the servlet engine was allowed to create more than one
> instance, this
> > > counter would not be accurate! As of 2.2, servlet authors can
> count on what
> > > has been standard practice all along -- only one instance of a
> non-STM servlet
> > > will be created in a container.
> > >
> >
> > What would happen to your hit counting servlet in a load balanced
> > environment? Doesn't each app server have its own container with its
> > own instance of the class?
> >
>
> You're correct -- in a load balanced environment, there will be an
> instance of the
> servlet in each JVM, and using an instance variable in the servlet no longer
> maintains your count correctly. If the data you are trying to maintain was
> user-specific, you could maintain the counter in a session and mark
> your app as
> "distributable" (2.2 API), and the server is supposed to copy your
> user session
> information when it moves you to a different server. But, for the
> sake of this
> example, we've been assuming that a global hit count was what we want, so this
> doesn't help.
>
> For maintaining a global shared variable that changes state like this in a
> load-balanced environment, you're going to need some external
> resource container
> (EJB, JDBC-accessed database, network-accessed file with suitable locking
> primitives, and so on) to store the shared state information, and use
> appropriate
> locking to make sure you don't lose any updates.
I agree.
In a uni-thread, uni-JVM environment, identity (of objects), communication
(among objects) and control (of execution) are easy. In a multi-threaded
environment, identity and communication are still trivial, but concurrent
execution needs to handled well. Luckily Java provides built-in techniques for
concurrency control - and programmers are advised to adhere to others. In a
multi-JVM, the problem are similar to a multi-threaded one (*) except that
there's no built-in support nor any built-in communication. We're really talking
about distributed computing (even if it's only for load-balancing), and if one
wants to implement object identity across JVM's, one needs to bring your own
(BYOS? :-), using EJB or CORBA or, in a more home-grown manner with RMI, RDBMS,
or other data stores (though using files would only postpone the problem of how
to sync the files).
I guess, if I were designing a servlet system which I knew would be deployed on
a multiple JVM environment, I wouldn't rely on instance or static variables in a
servlet or a context (or any other class for that matter) from the start. I'd
build a layer of proxies which let's one get/set 'global' variables. The proxy
objects would then be tasked with the details of synchronizing among themselves
across however many JVMs, physical machines, etc there are (using one (or more)
of the methods described before).
> ... connection pools ...
Sharing connection pools across JVM's probably isn't worth it since connections
are Berkeley sockets, with network addresses, ie, specific to the physical
machine (not the same as JVM, but still). It'd be better just to have a
connection pool per JVM.
Slightly off the subject: any multi-machine JVM's out there?
-s
* I guess if the JVM's are totally unhinged (no communication, no common
objects), control of execution is trivial too.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
