Checking the infinite loop database

I use JDBC, I need to constantly check the database for changing values.

What I have is an infinite loop, an inner loop repeating variable values, and every iteration check against the database.

public void runInBG() { //this method called from another thread while(true) { while(els.hasElements()) { Test el = (Test)els.next(); String sql = "SELECT * FROM Test WHERE id = '" + el.getId() + "'"; Record r = db.getTestRecord(sql);//this function makes connection, executeQuery etc...and return Record object with values if(r != null) { //do something } } } } 

I think this is not the best way.

Another way that I think of is the opposite to continue to iterate over the database.

UPDATE

Thanks for the tip about the timers, but I don't think this will solve my problem. As soon as a change occurs in the database, I need to process the results almost instantly against the changing values ​​("els" from the example code).

Even if the database does not change, it should still constantly check for changes in values.

UPDATE 2

Well, to everyone who is interested in the answer, I believe that I have a solution now. Basically the solution is NOT to use the database for this. Download, update, add, etc. Just what you need from the database to memory. Thus, you do not need to constantly open and close the database, you only deal with the database when you make changes to it, and reflect these changes in memory and do only what is in memory at that time. I am sure that this is a more intensive amount of memory, but performance is the absolute key here.

Regarding the periodic answers "timer", sorry, but this is not at all. No one answered for some reason how using timers would solve this particular situation.

But thanks again for the feedback, but it helped anyway.

+4
source share
6 answers

Another possibility: ScheduledThreadPoolExecutor .

You can implement a Runnable containing your logic and register it in a ScheduledExecutorService as follows:

 ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(10); executor.scheduleAtFixedRate(myRunnable, 0, 5, TimeUnit.SECONDS); 

In the above code, a ScheduledThreadPoolExecutor is created with 10 threads in the pool and Runnable will be registered on it, which will be launched in 5 seconds, starting from the moment it starts.


To schedule a launch, you can use:

scheduleAtFixedRate

Creates and performs a periodic action that is activated first after a given initial delay, and then with a specified period; that is, execution will begin after initialDelay, then initialDelay + period, then initialDelay + 2 * period, etc.

scheduleWithFixedDelay

Creates and performs a periodic action that is activated first after a given initial delay, and then with a specified delay between the completion of one execution and the beginning of the next.


And here you can see the benefits of ThreadPoolExecutor to make sure that it meets your requirements. I advise this question: Java Timer vs ExecutorService? too, to make the right decision.

+3
source

Saving while(true) to runInBG() is a bad idea. You better remove this. Instead, you can have a Scheduler / Timer (use Timer and TimerTask ) that will periodically call runInBG() and check for updates in the database.

+1
source

u can use a timer --->

 Timer timer = new Timer("runInBG"); //Taking an instance of class contains your repeated method. MyClass t = new MyClass(); timer.schedule(t, 0, 2000); 
+1
source

As you said in the comment above, if the application manages updates and inserts, you can create a framework that notifies the "BG" thread or process of a change in the database. Notification can be done over the network via JMS or an internal virtual machine using an observer pattern or both local and remote notifications.

You can have a general notification message (it can be a class for local notification or a text message for remote notifications)

 <Notification> <Type>update/insert</Type> <Entity> <Name>Account/Customer</Name> <Id>id</Id> <Entity> </Notification> 
0
source

To avoid a busy cycle, I would try using triggers. H2 also supports the DatabaseEventListener API, so you won’t need to create a trigger for each table.

This may not always work, for example, if you are using a remote connection.

0
source

UPDATE 2

Well, to everyone who is interested in the answer, I believe that I have a solution now. Basically the solution is NOT to use the database for this. Download, update, add, etc. Just what you need from the database to memory. Thus, you do not need to constantly open and close the database, you only deal with the database when you make changes to it, and reflect these changes in memory and do only what is in memory at that time. I am sure that this is a more intensive amount of memory, but performance is the absolute key here.

0
source

Source: https://habr.com/ru/post/1480633/


All Articles