|
Dear
Kevin,
thanks a lot on
throwing some more light on MVC model. I had done one more project on the
same pattren. I concluded this drawback (efficiency brought down) by
noticing one thing, at times we were used to get an exception. DEAD LOCK
CONDITION. Was it cause of bad implementation.
In senarios where
u have to Access DB very frequently and thrown back a lot of data (for example
in select combos) to the web page after data retrieval (not to forget the time
wait coz of DB locks).
Will it still be
that much efficient ?
Now if we
maintain a pool that is we have more than one servlet. there is a probability of
data inconsistancy. I mean if there is a node and we can create a node
underneath. Now isnt this possible that one client deletes that node and at the
same time other person sends a request for creating a node underneath
?
I will be grate
ful to you for ur comments on this. Please correct me where i am
wrong.
Cheers!!
raj
P.S. --
please elaborate ---- >> " It allows multiple requests from any
number of clients to all hit the same one single instance of a servlet class.
The reason this is optimal is only a single instance is
created.."
Fellas..fellas..let me attempt to come to the
rescue..
As a
developer of an MVC framework ( Theseus at www.brainopolis.com/theseus ), I
have at least some insight into this. First off, the controller servlet, or
for that matter ANY servlet can indeed be a singleton..but why? It limits a
servlet to just one thread at a time, OR, ir the servlet container wants..it
can implement a "pool" of servlet instances (for each servlet class) for you,
in which each request that comes in can be handled by an instance of the
servlet class from the pool it maintins of each servlet. However, if you
follow a few simple guidelines, you NEVER need to worry about this. First, for
optimum performance, using just one single instance of each servlet is the
best way to go. It allows multiple requests from any number of clients to all
hit the same one single instance of a servlet class. The reason this is
optimal is only a single instance is created..usually when the app is started
or upon the first request. It conserves memory, eliminates the need to create
and garbage collect servlet class instances. The hard part is..you can not use
any "global" variables in the class. However..this is simple enough to avoid
because in the doPost() or doGet() ( or service() ) method, you create all
your variables locally in the method. If you need to call another method, you
pass to it the variables it needs, such as the
HttpServletRequest.
Raj,
your wrong about the effeciency bring brought down. A good MVC framework such
as my own, or Struts, using just one single instance is VERY capable of high
loads on a single server. As fast as cpus are, you can run literally hundreds
of millions of instructions per second. Even with Java being interpreted, the
JIT often converts byte code to native as it sees the need, the result being
that a single servlet will most likely never be the bottleneck in a web
application unless its inundated with WAY too many requests that the server
itself can't handle. In that case, you "scale"...add more servers, use load
balancers, etc.
To
the original poster, go grab my framework, or grab Struts. Join the Theseus or
Struts mailing list, and start using it. It will simplify your life. You don't
have to write tons of servlets..you use the MVC framework and write action
classes that hides all the servlets stuff for you. MVC implemented improperly
can definitely cause problems, but when implemented properly it will infact be
the opposite..allowing much faster web development with a lot less hassles. As
for syncronizing..you never need to worry about that. Because all variables
are created within each method, they belong to the context of each request.
Keep in mind, each time a request comes in, the servlet container creates a
new thread for that request and all variables created in the methods are part
of the thread's stack frame..so each request is "safe" from another thread.
However, don't let that confuse you..if you pass in a instance field of a
servlet, ALL requests have access to the same one instance field. This can be
a good way to keep a counter for how many requests to a given servlet have
occurred.
Feel
free to ask any questions.
that is the
problem with MVC model. There is a huge bottle neck at the servlet that
brings down the efficiency. In a MVC we have only one servlet if we have
more than that .
in that
scenartion two clients can modify the same data.
Cheers!!
raj
What makes you believe that the Controller Servlet in the MVC
model has to be a Singleton Class.
Another thing as per my limited knowledge having a singleton class
doesn't mean that it implements a SingleThreadModel interface.It only
means that whenever the static getInstance method of the class
is called only one instance would be returned and the Class has a
private constructor which helps in achieving the above mentioned
behaviour.
The performance of an application could suffer if the Controller
Servlet implemented the SingleThreadModel interface in my opinion.
Looking forward to your (Mr. Sandhu) as well as
others comments.
----- Original Message -----
Sent: Thursday, August 02, 2001
12:35 PM
Subject: Re: MVC Issue
There is
no need for synchronizing the process method in the request handlers in
the MVC model.
As the
controller servlet is a singleton class (implements single thread model)
i.e. two threads cant call the service method concorrently. so no two
clients can call the same process method of the request handler. you can
say Servlet works as a synchronizing agent. (Or actually synchronization
never takes place/ reqiured ).
Cheers!!
raj
Hello Jspians,
I'd just like to get your
comments on the following :
In the MVC model, each action class has a process(...) or similar
method.
I'd like to know if there is a need to synchronize this
method.
Looking forward to your comments.
|
