int time = 0;
time++; // set by 1second
int countdata = 0; // countdata queried by table shows the numbers of table values
rs = stmt.executeQuery("SELECT ID,test From Table");
StringBuilder strBuilder = new StringBuilder();
while (rs.next()) {
strBuilder.append(rs.getString(0)).append(" ").append(rs.getString(1));
strBuilder.append("\n");
if(time <= countdata){
// this is my idea but i dont know how to fetch the data each row
}
jtextarea.setText(strBuilder.toString());
}
the output is like this:
// time 1 seconds
test1
// time 2 seconds
test2
// time 3 reconds
test3
//until it reach the last data of table
please help
i want to fetch data by every 1 second until it reach the last value. the time is fix by 1 second delay. every 1 second shows the row of data.
You have two basic choices (there are others, but lets keep it simple...)
Basically, you want to perform the query in some kind of background thread but ensure that the updates to the UI are carried out within the context of the Event Dispatching Thread...
This ensures that while the query is taking place, the UI remains responsive to the user and to won't make it look like your application has crashed...
You Could...
Use a Swing Timer to schedule a call back every n milliseconds. The benefit of this is that it the callback is triggered within the context of the Event Dispatching Thread.
The drawback is that the callback is triggered within the context of the Event Dispatching Thread.
The main problem I see is you don't want to be querying the database from the context of the EDT as this will prevent it from performing updates to the UI and remaining responsive to the user while the processing is occurring.
Now you could spawn another Thread at this stage, but the problem is, the time it takes to complete the query may be more than the time allocated between updates, meaning that it would be possible for last query to still be running when the next one is triggered. You also run into issues with having to synchronise updates to the UI manually, while not especially difficult, why would you want to make life more difficult ;)
Take a look at How to Use Swing Timers and Concurrency in Swing for more details
You Could...
Use a SwingWorker. This will allow you to perform the query in a background thread while providing you with functionality to send updates back to the Event Dispatching Thread so the UI can be updated properly.
The drawback with this is that the SwingWorker doesn't have timer concept of it's own, but, you could simply use Thread.sleep.
Now, depending on whether you want regular updates; ie they MUST occur every second, exactly, or delayed updates; ie they must occur every second AFTER the last update will depend on how you use this, but what this means is you gain control.
Basically what this means is, you can ensure that only one query is been executed at a time and control the amount of time before the next one.
Take a look at Worker Threads and SwingWorker for more details
Related
Scenario: One thread is being called up to thousands of times per second to do inserts to the same table and is currently doing them one-by-one.
Goal: Do periodic batch inserts instead to improve performance.
Trying to use a TimerTask to instead add objects being saved to a list as the thread's saveItem method gets called, then combine them for a batch insert every 2 seconds or so.
First thought was to have two Lists, call them toSave and toSaveBackup. When the thread's saveItem method is called to save something it will be added to the toSave list, but once the TimerTask kicks off and needs to save everything to the database, it will set an AtomicBoolean flag saveInProgress to true. This flag is checked by saveItem and it will add to toSaveBackup instead of toSave if saveInProgress is true. When the batch save is complete, all items will in toSaveBackup will be moved to the toSave list, probably with a synchronized block on the lists.
Is this a reasonable approach? Or is there a better best practice? My googling skills have failed me so any help is welcome.
Misc info:
All these inserts are to the same table
Inserts are driven by receipt of MQTT messages, so I can't combine them in a batch before this point
Update: A tweak on CKing's answer below achieved the desired approach: A TimerTask runs every 100 ms and checks the size of the saveQueue and how long it's been since a batch was saved. If either of these values exceed the configured limit (save every 2 seconds or every 1000 records etc) then we save. A LinkedBlockingQueue is used to simplify sychronization.
Thanks again to everyone for their help!
It looks like your primary objective is to wait for a predefined amount of time and then trigger an insert. When an insert is in progress, you wan't other insert requests to wait till the insert is complete. After the insert is complete, you want to repeat the same process again for the next insert requests.
I would propose the following solution with the above understanding in mind. You don't need to have two separate lists to achieve your goal. Also note that I am proposing an old fashioned solution for the sake of explanation. I cover some other APIs you can use at the end of my explanation. Here goes :
Define a Timer and a TimerTask that will run every N seconds.
Define an ArrayList that will be used for queuing up insert requests sent to saveItem method.
The saveItem method can define a sycnrhonized block around this ArrayList. You can add items to the ArrayList within this synchronized block as and when saveItem is called.
On the other side of the equation, TimerTask should have a synchronized block on the same ArrayList as well inside its run method. It should insert all the records present in the ArrayList at that given moment into the database. Once the insert is complete, the TimerTask should clear the ArrayList and finally come out of the synchronized block.
You will no longer need to explicitly monitor if an insert is in progress or create a copy of your ArrayList when an insert is in progress. Your ArrayList becomes the shared resource in this case.
If you also want size to be a deciding factor for proceeding with inserts, you can do this :
Define an int called waitAttempts in TimerTask. This field indicates the number of consecutive wake ups for which the TimerTask should do nothing if the size of the list is not big enough.
Everytime the TimerTask wakes up, it can do something like if(waitAttempts%3==0 || list.size > 10) { insert data } else { increment waitAttempts and do nothing. Exit the synchronized block and the run method }. You can change 3 and 10 to whatever number suits your throughput requirements.
Note Intrinsic locking was used as a means of explaining the approach. One can always take this approach and implement it using modern constructs such as a BlockingQueue that would eliminate the need to synchronize manually on the ArrayList. I would also recommend the use of Executors.newSingleThreadScheduledExecutor() instead of a TimerTask as it ensures that there will only be one thread running at any given time and there wont be an overlap of threads. Also, the logic for waitAttempts is indicative and will need to be adjusted to work correctly.
I'm doing a Swing application where in one of its forms, I have a table which I want to update periodically. I first thought of using a Timer, but the task may be time consuming and it may freeze the GUI. Then, I thought of using a SwingWorker, but it is designed to be executed once, and I need to execute this task periodically (every two or three minutes) while the form is open.
In this form's code I have implemented three methods: acceptNew(), which runs a quick UPDATE query, listRequests(), which runs some queries to fill an ArrayList with all the records; and manipulateTable(), which compares the table model with the ArrayList and updates/inserts the records.
In short, acceptNew() does a quick task, listRequests() does another task which its completion time depends of the number of records in the DB, and manipulateTable() updates the GUI. I need to call these three methods periodically without freezing the GUI.
You can use SwingWorker's publish to emit the new state of listRequests() that you call manipulateTable() in the process method and sleep inbetween.
Or just create and submit a new SwingWorker that updates it once every time from a Timer.
I want to delete duplicate record in my database table, and I do it in java by using this query
String sql = "DELETE e1 FROM tweet_after_preprocessing e1, tweet_after_preprocessing e2 WHERE e1.tweet = e2.tweet AND e1.tweet_after_preprocessing_id > e2.tweet_after_preprocessing_id"
The problem is when there are so many records in my database table, the process will take so long, and make my program look not curently running.
and I want to use progress bar to show progress of the executing, how can I do that?. I don't now the maximum and the minimum value, so how can i accessing the progress bar?.
You can create an indeterminate progress bar by setting the property indeterminate to true: JProgressBar.html#setIndeterminate().
Also it is wise to not execute long lasting work in the EDT but use a different thread for this.
The problem is that you're doing all your work on the EDT, which is blocking your GUI. You need to do the loading on another Thread, so your GUI can still update, display, and respond to user input.
Once you have the work on another thread, then from that thread, you can post updates to the EDT using the SwingUtilities.invokeLater() method.
You could also look into the SwingWorker class, which handles some of that for you.
Recommended reading: http://docs.oracle.com/javase/tutorial/uiswing/concurrency/
Excellent question.
Jenkins uses the time of the last build to guess how long the current build will take to run. So for example if the last time a build ran it took 10 minutes, and it is 5 minutes into a current build it will show that it is 50% complete.
You can do something similar. Maybe query the DB first to see how many items need to be deleted and have a table of how long it will take for the amount of items being deleted and how many items are in the table.
I'm using JDBC, need to constantly check the database against changing values.
What I have currently is an infinite loop running, inner loop iterating over a changing values, and each iteration checking 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'm think this isn't the best way.
The other way I'm thinking is the reverse, to keep iterating over the database.
UPDATE
Thank you for the feedback regarding timers, but I don't think it will solve my problem.
Once a change occurs in the database I need to process the results almost instantaneously against the changing values ("els" from the example code).
Even if the database does not change it still has to check constantly against the changing values.
UPDATE 2
OK, to anyone interested in the answer I believe I have the solution now. Basically the solution is NOT to use the database for this. Load in, update, add, etc... only whats needed from the database to memory.
That way you don't have to open and close the database constantly, you only deal with the database when you make a change to it, and reflect those changes back into memory and only deal with whatever is in memory at the time.
Sure this is more memory intensive but performance is absolute key here.
As to the periodic "timer" answers, I'm sorry but this is not right at all. Nobody has responded with a reason how the use of timers would solve this particular situation.
But thank you again for the feedback, it was still helpful nevertheless.
Another possibility would be using ScheduledThreadPoolExecutor.
You could implement a Runnable containing your logic and register it to the ScheduledExecutorService as follows:
ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(10);
executor.scheduleAtFixedRate(myRunnable, 0, 5, TimeUnit.SECONDS);
The code above, creates a ScheduledThreadPoolExecutor with 10 Threads in its pool, and would have a Runnable registered to it that will run in a 5 seconds period starting immediately.
To schedule your runnable you could use:
scheduleAtFixedRate
Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given period; that is executions will commence after initialDelay then initialDelay+period, then initialDelay + 2 * period, and so on.
scheduleWithFixedDelay
Creates and executes a periodic action that becomes enabled first after the given initial delay, and subsequently with the given delay between the termination of one execution and the commencement of the next.
And here you can see the advantages of ThreadPoolExecutor, in order to see if it fits to your requirements. I advise this question: Java Timer vs ExecutorService? too in order to make a good decision.
Keeping the while(true) in the runInBG() is a bad idea. You better remove that. Instead you can have a Scheduler/Timer(use Timer & TimerTask) which would call the runInBG() periodically and check for the updates in the DB.
u could 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);
As you said in the comment above, if application controls the updates and inserts then you can create a framework which notifies for 'BG' thread or process about change in database. Notification can be over network via JMS or intra VM using observer pattern or both local and remote notifications.
You can have generic notification message like (it can be class for local notification or text message for remote notifications)
<Notification>
<Type>update/insert</Type>
<Entity>
<Name>Account/Customer</Name>
<Id>id</Id>
<Entity>
</Notification>
To avoid a 'busy loop', I would try to use triggers. H2 also supports a DatabaseEventListener API, that way you wouldn't have to create a trigger for each table.
This may not always work, for example if you use a remote connection.
UPDATE 2
OK, to anyone interested in the answer I believe I have the solution now. Basically the solution is NOT to use the database for this. Load in, update, add, etc... only whats needed from the database to memory. That way you don't have to open and close the database constantly, you only deal with the database when you make a change to it, and reflect those changes back into memory and only deal with whatever is in memory at the time. Sure this is more memory intensive but performance is absolute key here.
I am a Java newbie and an Android newbie too. I am working on a game and trying to understand the exact nature of events in Java and Android. I have a few questions to help understand the correct way to do event handling in my app.
Its a network game and so I need to check if the user made a move or not to update the view. Also I need to prompt the user to make a move if he takes too long. For this I have two threads -
Timer thread expires every 10 seconds and calls updateview if needed or prompts user to make a move.
Event thread gets created when user clicks on the screen to make a move or clicks on menu etc.
Is this the correct approach? These two can be fired at any time.
Here are the issues I see with this -
What happens when one thread gets run when the other one is active.
Which thread has precedence if both are started at the same time.
Do events in the timer thread get queued up?
If so can I pick which one in the queue to use?
Can I cancel events in the queue? For e.g. if I have 2 updateview events lined up in the queue I only have to call it once.
Thanks for any inputs.
P
I would suggest reading up on Android AsyncTask.
Consider that you can implement a timer WiTHOUT using a thread. Use a single Handler switching on what and send a postMessageDelayed(what 0,milliseconds) to the handler say every one second. You could set a counter variable to zero and check the flag every one second in the what 0 handler, incrementing the counter by one. If the value is >= ten, post a message and reset the variable to zero. If the user selects an action, reset the instance variable to zero.
A time consuming action can be run in a separate thread that messages the handler, perhaps using what 1, on completion. Or you could run a time consuming action in a separate asyncTask.
JAL