Re: Help - Timing Logic
- From: "jeff" <jhersey at allnorth dottt com>
- Date: Tue, 28 Nov 2006 08:56:05 -0800
Still do not know why you need 4 threads ? Speed ? Does runnig the process
in one thread not work fast enough for you since timing is import ? Why 4
threads why not 6,12 , 3, 36 ... ? How do you determine which row a
'thread retrieves' ??? does it simply select the next available row from the
DATABASE ??? How does the thread determine 'the next row'???
If mutli-threading is duplicating 'send messages' it is not working
properly...
If you are multi-threading to improve performance ... maybe look at the
design...
If you need to implement a locking mechanism / or / logging mechanism / or /
a checking mechanism to avoid duplicate messages caused by multi-threading
.... these will all come at a cost ... performance cost!
What is bottle necking your process that you need 4 threads? Is it the READ
from the database ... is it the SENDING the text message? Is it connecting
to the database ??? do not know here ...
Look at what is causing problem ...
- you need better performance ... so, multiple thread it! However,
mutli-threading the entire process is causing issues ... duplicate records
.... now you either need to incorporate a locking procedure ... or a checking
procedure to avoid duplicate messages... all this has a cost to the overall
performance ... adding more threads may in fact negatively impact the
overall performance....
Maybe implement a message broker ...
- message broker gets all the necessary messages or message id's from the
database to be sent ... in-memory list...
- message broker loops through list of messageIDs ...
- message broker starts another thread for processing the sendtextmessage
functionality for each messageID...
- message broker will include the messageID so the process knows which
message to get and process...
- message broker will ensure each database row is only processed once...
It is very hard to help you without knowing exactly what you are doing...
Again, I will ask, what rational / reasoning did you use for using 4 threads
? Performance ? Speed ? ... Where is the bottle neck in the process that
requires you to multi-thread it? Maybe just move the 'bottle neck section'
to another thread ... ?
Grasping at straws ...
Code would be nice how to see what you are doing ...
Jeff
"Jay" <someone@xxxxxxxxxxxxx> wrote in message
news:uBX7QewEHHA.1224@xxxxxxxxxxxxxxxxxxxxxxx
Thanks. I do need to select an individual row at a time and all 4 threads
need to do this. What trasaction isolation level would you recommend?
Perhaps a stored proc may be faster to execute and return the values as
opposed to building the transaction in the code. What has to happen is
every 5 seconds, and for each thread, a sub runs to get a single row then
send the message to dtr("numbertosendto"). Because this app heavily
relies on timing it is important that all threads run and only one
distinct row can be returned at a time for each thread.
"jeff" <jhersey at allnorth dottt com> wrote in message
news:%23qVFIYwEHHA.3576@xxxxxxxxxxxxxxxxxxxxxxx
are you selecting individual rows at a time from the database table ...
if so ... use a transaction ...
begin transaction ...
select a row from database ...
update the row in table set flag = 'Processed'
end transaction
this will lock the row until the end of transaction is issued ... as long
as the isolation level is set accordingly...
Again, please let us know how you are getting the information from the
database... then we can help!
If you are reading a bunch of rows in one statement, storing the rows in
in-memory datasets on the workstation, looping through the rows one by
one ... then you may need to either ...
implement as above locking only the records you retrieve / update - need
to watch out here for table locking ... may impact performance,
implement using an update flag at sent and 'check before send method'...
...
lots of options here, just need to know how you are retrieving your
data...and how you are processing the data.
Question, why do you need 4 threads running ... are they doing 'different
processes', sending different 'types' of messages ... sending the same
message ... just need 4 to make it faster ... what is the logic ...
Tieing a record to a thread my cause problems in the future ... what
happens when a thread stops or hangs ... those messages will not be
processed... When happens if somebody changes the ThreadID ... in the
program ...
trying to help ..
Jeff
PS: you can lock individual rows ... look at how database transactions
work and incorporate it in you program ...
"Jay" <someone@xxxxxxxxxxxxx> wrote in message
news:%23f70LJwEHHA.2328@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for the reply.
I do need all 4 threads running (maybe even more in the future). I can
not delete the row from the table... it needs to be there for later
update use. I am considering marking each row at insert (1 - 4) then
having each of the 4 threads only select a row based on the mark. It's
becoming a little tricky... it would be great if I could lock a single
row when selecting it.
"jeff" <jhersey at allnorth dottt com> wrote in message
news:OPCyvDwEHHA.4740@xxxxxxxxxxxxxxxxxxxxxxx
Question:
What is the reason for the 4 threads?
Do you need all these threads processing the same dataset?
Just asking, maybe you could change your approach to avoid this
problem...
If not, investigate Record Locking / Transactions...
How are you retrieving your records in to memory for processing ...
ie,
- are you selecting on the entire contents of a 'message' table and
looping through an in-memory dataset...
- do you retrieve 'chunks' or rows from the message table based on
parameters...
You could use the internal locking mechanisms of the database to
achieve this ... but procede with caution...
Start Transaction...
SELECT * FROM MESSAGE TABLE
...
stuff this into a data table on the desktop
...
DELETE * FROM MESSAGE TABLE
...
punt / clean the table.
...
End Transaction.
The transactions places locks on the table ... but selecting the entire
tables contents ... you are essentially 'LOCKING' the entire table
until the transaction is over...
So, each thread's 'retrieve' process will have to wait in line until
the select and delete are processed. As well, anything triggering 'New
Messages to be Added' will be delayed until the Transaction is
completed...
You may impact the overall performance of you application ... need to
investigate.
If locking does not work for you, you will need to implement some type
of logging / checking approach...
ie... have a log table...once a process has sent the message, write to
a log table ... message sent. Before each message is compiled and
sent, check the log table to see if another process has sent the
message...if not, send you message...
A snip of code would be great to figure out how you are retrieving a
list of messages and how you are processing each record...
Jeff.
"Jay" <someone@xxxxxxxxxxxxx> wrote in message
news:O2phzwvEHHA.4280@xxxxxxxxxxxxxxxxxxxxxxx
I have a multi threaded VB.NET application (4 threads) that I use to
send text messages to many, many employees via system.timer at a 5
second interval. Basically, I look in a SQL table (queue) to determine
who needs to receive the text message then send the message to the
address. Only problem is, the employee may receive up to 4 of the same
messages because each thread gets the recors then sends the message. I
need somehow to prevent this... just can't think of how. Somehow I
need the other threads to know that another thread is already using
that record and move on to the next record. I thought of getting the
record then marking it (column value) as in use and writing the code to
look for records only where not in use... problem is all 4 run fast
enough to all use/mark the row. Any thoughts?
Thanks a lot.
Jay
.
- Follow-Ups:
- Re: Help - Timing Logic
- From: Jay
- Re: Help - Timing Logic
- References:
- Help - Timing Logic
- From: Jay
- Re: Help - Timing Logic
- From: jeff
- Re: Help - Timing Logic
- From: Jay
- Re: Help - Timing Logic
- From: jeff
- Re: Help - Timing Logic
- From: Jay
- Help - Timing Logic
- Prev by Date: Adding Dropdownlist to GridView
- Next by Date: Re: HttpWebRequest POST no longer working to Canada Post website
- Previous by thread: Re: Help - Timing Logic
- Next by thread: Re: Help - Timing Logic
- Index(es):
Relevant Pages
|
