Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

intense database access

Status
Not open for further replies.

leoliang

Programmer
Dec 9, 2003
27
CN
hi,there

I am working on a industry automation project which needs frequent database access in like every 5 seconds to write information back to database. I dont want the database operation affect the main function. so is there a good way to deal with this problem? thanks in advance.

angler
 
Doesnt sound overly intensive, but you may want to look at putting the data access methods in a seperate thread.


Sweep
...if it works dont f*** with it
curse.gif
 
but be very carefull that you make sure the previous thread has finished bfore starting a new one. Or you could end up updating a record that hasn't been inserted yet. Or something like that.

Christiaan Baes
Belgium

I just like this --> [Wiggle] [Wiggle]
 
A singleton design pattern that launches another thread to update a record would be your best bet. It seperates the IO for the display process which will keep the GUI working and looking good, and the singleton design pattern will prevent more then one object (and thus thread) from being created.

Another option would be to run a queueing system in combination with a thread.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
[monkey]I believe in killer coding ninja monkeys.[monkey]
 
Every five seconds isn't that often, but if it takes CPU time away from your data collection, you could miss some samples.

This sounds like a good use for the producer-consumer pattern.

You have one thread or process that is producing data (your collection routines) and another that is consuming it. Google is your friend on this.

Chip H.




____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
thank you guys so much.

I did some research on singleton design pattern and producer/consumer pattern today. both of them are really nice idea to handle this issue.

for the sigleton way, I dont have to synchronize many threads as there is only one db thread. by raising the events, i can let the db thread perform db operation. my question is if it is possible there are too many events so that the thread couldn't handle it in time.

it also looks I can combine the concepts of singleton and producer/consumer together, use the singleton thread as the consumer, the main thread as the producer.

If I choose to use multithread, can i make it work by doing the following?

dim mylock as string = "lock"
synclock mylock
'open db
'db operations
'close db
end synclock

each time a new thread is created, the thread will invoke the code above. actually maybe I also can use "mutex" as another alternative.

can you please let me know what you think? thanks a lot.

angler
 
I wouldn't put the lock around the database access. Instead, I would put the lock around an array copy operation.

It would work something like this:

1. Producer collects data from your hardware, puts the samples into an array, using the lock to protect access.
2. Five seconds pass
3. Consumer wakes up, uses the lock to gain access to the array, copies the contents of the array to it's own private array, zeros out the shared array, releases the lock.
4. Consumer is now able to write to the database at his leisure, using his private copy of the data
5. Producer is only locked out from writing data to the shared array for the time it takes to make a copy, so his impact is minimal.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top