• Post Reply Bookmark Topic Watch Topic
  • New Topic

Threads management for daemon programs

 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is the architecture. We have multiple daemon threads running on the same JVM, these threads perform different but similiar database operations. Their lifecycles are basicly like this:



Different thread will use differnt set of tables.

Here are my questions:

1) How to manage these threads. I am assuming these threads will compete with each other for the CPU cycles, right? So if I want to set the priority (or CPU usage) of a thread, I can set its wait time, is that a good approach?

2) The way these threads are deployed is through the init() method of a servlet running within Tomcat, Since we want to start them automatically when Tomcat being started. Is it good? Any other way?

Thanks
[ April 12, 2006: Message edited by: Yuan Ye ]
 
Andreas Schaefer
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think that is a good design. You are waisting many CPU cycles when there is no data to be processed. Also you data processing is done outside of a transaction causing a wide range of problems.

I would suggest that you create a MDB that does the processing and that however puts data into the source table kicks of the MDB by sending a JMS message. Of course this only works for some scenarious and may be not applicable to your situation.

That said it is hard to judge your design when you do not provide more information about the system, requirements etc.

-Andy
 
Yuan Ye
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Andy. Thanks for the reply. Here is a little more detail:

First, there is no J2EE framework setup. For transaction protection, I write my own JDBC commit() or rollback() for user transaction. For global transaction, there is nothing, I am betting on my luck. (Because it is so difficult to implement with JDBC)

Second, it is a hybrid system. Java, C++ and SQL can all write into the DB. C++ developers don't want to drop a MDB message when they put something into DB. So the db monitoring has to be proactive instead of reactive. Yes, a lot CPU time will be wasted while checking.

Third, Actually there are queue components used in the system. Either DB1 or DB2 can be a queue (oracle advanced queue), because of its auto retry feature. But I don't know how to catch the enqueuing message for the queue.

Given that, must be straight JDBC + Threading. What do you think the important things are that I need to pay attention? Is it true I must co-ordinate the threads sleeping times right? If a thread is not sleep at all, it will eat up all cpu cycles and not giving other thread a chance to run, is that correct?

Thanks.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!