I am working on a j2ee project(jsp/servlet) with JBoss as server where i need to manage hits also from the server side and code side.Some times this project need to handle above 20000 hits/minute.
1. I am using conventional DB connection not using DBCP,is DBCP essential?.
2. We are using a thread for updating application variable with an interval of 30 seconds for taking DB data.This data is then added to Hash Map and Hash Map is put into the application variable.The jsp page will populate data from Application variable.
A connection pool is a fairly standard thing in a JEE application, and would be useful for your situation. You can declaratively control the number of connections available to your application and stop it swamping your database. What are you doing instead? A connection per thread?
Are you saying you have manually spawned threads in your Servlet? If so, the specification warns against this. It also sounds like you are sharing access to a HashMap across multiple threads - in which case you will need to be careful to synchronize access to this. beacure your design requires you to introduce synchronization it makes it a less than optimal choice for an application with a very high load.
Thanks for your REPLY.
I am used connection per thread.
i am sharing the code for scheduler which runs on server startup and update application variable frequently.Here getData() returns Hash Map object ,is it is the best method,or use Hash Table?.Is it is convenient for us to work on high load environment(hits above 20000/minute).No only that, do i make jsp's 'ThreadSafe'. Please suggest.
Not sure why you are using a Thread for this at all. You load your Map of application data in the init method of a Servlet. There is only one instance of this Servlet (per container - if your application is deployed in a cluster there will obviously be more), so why use a Thread to do it at all? Maybe you can explain your thinking a bit?
Here getData() returns Hash Map object ,is it is the best method,or use Hash Table?
There is never any need to use Hashtable. If your use of this Map is read only then you don't have any problems. If its not, you will need to synchronize access, which would be a bad thing in an applcation that is going to have a high load.
Joined: Jul 05, 2010
1. ....o why use a Thread to do it at all? Maybe you can explain your thinking a bit?
I need to reduce frequent database call and need to get updated data from the database too. Thats why i used thread,and it will update application variable with updated data.Is this code produce any server overhead as the number of hits increases.
Ah - so you are caching changing data, rather than read only data. In which case access to your Map is going to have to be synchronized, which is a bottleneck. Any reason you don't just hit the database for this? It seems to me to be a better plan to spread the load rather than force it though a single access point. Databases a pretty good at handling concurrency, and it seems a bad design to potentially block a thread's access to your Map if another thread is accessing it, especially if the data these two threads use is completely unrelated. Most decent databases should be OK with the load you are suggesting, assuming you've bought a decent server to host it.
I can't think of many good reasons for implementing runnable for a servlet.
If it's just because you have a long running task?
Since your already using JBoss, you may want to look at using a Message Bean (MDB) to make the request for data, then have your client check back later to see if the request has completed.
"Stay on the path."
Joined: Jul 05, 2010
Thanks for Your Reply.
But i am used this thread for managing hits. Because each client just read the application variable,so no need to go directly to the database.Not only that the database data is not changing frequently.The jsp page have "meta Refresh" tag so that to get updated data on refresh.
Please suggest a solution to limit database access call.
Still think its going to be a bigger bottleneck having a synchronized block in your application code than just letting the database be hit. It's probably worth testing both. Also, how do you maintain state in your simple cache if you deploy your application on more than one Servlet container? This would be a must if you are worrying about throughput.
If this is a common query the database will optimize it by caching both the statement and the data. Over time this will get faster - synchronized code will not.