|
I am
no expert on the topic of deadlocks, but I would suggest allow an EJB container
with transactions handle this for you. By using Theseus, you do a JNDI lookup of
an EJB in an action class method. You then have the EJB start the transaction,
get your data, commit the transaction and return the data to the web tier action
class, which forwards on to the JSP page to display it. The EJB container is
able to handle caching of entites and working with connection pools and instance
pools as part of its implementation. The web tier should only be concerned with
handling the web specific stuff, such as displaying the data and validating
fields and what not.
Ofcourse all sites are limited to bandwidth and
overload..so I guess it is entirely possible that a site could have two or more
people access the same data. Generally, the EJB container would lock a row or
rows while any possible updating is being done, so that the second or third user
would see a little longer delay in their return. When the first person's
transaction is done, the second person would then be able to get their page back
as the EJB their session is using would now be able to do its database
work.
I can
tell you the company I work for is using my framework no problems, but we have
at most 30 or so users at the same time doing searches. Alot of our queries are
extensive, searching over 2GB of data at a time with complex joins. We are not
using EJB either at this time and infact are suffering from severe slowness of
transactions involving the database. At this point, our persistence engine is
the major culprit and we are looking at going to EJB very soon to resolve this
issue.
Lastly, I'd like to say I don't know if its the
language barrier or just the lack of detail, but I am having a hard time
understanding what it is your app is to do and the problems you have. Maybe if
you reply with more detail and specifics, I can be of more
assistance.
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.
|
