wood burning stoves 2.0*
The moose likes Performance and the fly likes Is this a good approach? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Performance
Bookmark "Is this a good approach?" Watch "Is this a good approach?" New topic
Author

Is this a good approach?

giang nguyen
Ranch Hand

Joined: May 13, 2003
Posts: 42
I need a fast search solution for my appliation.
Basically, the multiple users will perform a search based on not very large and fairly stable database (not updated often). My resposibility is to ensure that the search should return very quickly.
If a large number of users all connect to the database to perform the search, this would be difficult.
I have an idea as follows:
+ As the data explored by search is not large maximum 250 records), I intend to place it in the servlet context which is shared by all users. Then they can perform the search without having to consult the the database.
+ Whenever there're a update in the database I turn the flag databaseChange on, so the search function will now refresh the data in servlet context with new data from the static database. The search funtion will check the flag every time it performs the search to ensure the up-to-date.
Any idea is welcome.


SCJP 1.4, SCWCD
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by giang nguyen:
If a large number of users all connect to the database to perform the search, this would be difficult.

Would it? How do you know?
Couldn't you get the database to do some indexing and/or caching if needed?
BTW, why are you using a database for 250 records?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Re: the update flag. After a new update is received, how long would the update flag stay true? After the servlet sees the flag is true and so refreshes its content from the DB - what happens the next timeit needs to do a search? Does it check the flag again? Is it still true? How does the servlet know whether the update it last refreshed from is good enough, or whether there's a newer update available?
Maybe the servlet sets the update flage to false each time it refreshes from the DB. Aside from possible concurrency issues (what if the DB receives an update while the refresh is occurring?), what if there's more than one servlet running, e.g. on different machines, connected tothe same DB? Is that possible? Is the update flag attached to the DB, or the server? Who sets it to true, and who sets it to false?
I suggest that if you do use a scheme like this, it would probably be better to store the time (and date) of the most recent update. That way any servlet can read the last update time from the DB, and see if it's later that the last refresh done by that servlet. (Each servlet would have to store the time of their last refresh.) Make sure all times are obtained from the same source.


"I'm not back." - Bill Harding, Twister
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
Unless you're expecting 1000+ concurrent users I can't imagine how a 250 record database could become a performance bottleneck...
You might consider using something along the lines of Prevayler.
giang nguyen
Ranch Hand

Joined: May 13, 2003
Posts: 42
Originally posted by Jim Yingst:
Re: the update flag. After a new update is received, how long would the update flag stay true? After the servlet sees the flag is true and so refreshes its content from the DB - what happens the next timeit needs to do a search? Does it check the flag again? Is it still true? How does the servlet know whether the update it last refreshed from is good enough, or whether there's a newer update available?
Maybe the servlet sets the update flage to false each time it refreshes from the DB. Aside from possible concurrency issues (what if the DB receives an update while the refresh is occurring?), what if there's more than one servlet running, e.g. on different machines, connected tothe same DB? Is that possible? Is the update flag attached to the DB, or the server? Who sets it to true, and who sets it to false?
I suggest that if you do use a scheme like this, it would probably be better to store the time (and date) of the most recent update. That way any servlet can read the last update time from the DB, and see if it's later that the last refresh done by that servlet. (Each servlet would have to store the time of their last refresh.) Make sure all times are obtained from the same source.

Thanks Jim Yingst,
Actually, only the component that's reposible for maintaining the data is able to set the flag true. The flag is actually a variable that's set into the servlet context and shared by all servlets. Once the DAO component change the database, it will set the flag to true. Then any search servlet that first perform the search will see that, the flag is true then instead of querying data from the servlet context variable (the one that hold data), it queries data directly from database and update the servlet context variable to the new value and at the same time set the flag to false. Other search servlet see the false flag and dont have to go a long way to DB to get data, it can get data direclty from the servlet context variable.
My question is: is this an improvement comparing to querying database every time a search is needed (remember the database is not frequently updated)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by giang nguyen:
My question is: is this an improvement comparing to querying database every time a search is needed (remember the database is not frequently updated)

Possibly. It really depends on the setup - where is the database server running (different continent? in memory of the same JVM?), how the database is configured (caching, indexing) etc.
What it *invariably* will do is making the system more complex and therefore harder to maintain, harder to extend and more vulnerable to bugs. Therefore I would strongly advice *against* using the approach until you have *proven by experiments* (profiling) that you really need it.
 
GeeCON Prague 2014
 
subject: Is this a good approach?