I read several doc that told me that if i want to make a realtime application, i should use MySQL Cluster. So this is what i done.
But i wasn't able to find how to make a JTable updated each time a value in the MySql Cluster was updated.
Do you have any links or example that can help with my issue.
Thanks in advance.
Is your java app the one performing the updates on the database or is possible for other processes to make changes?
If only your app is making the changes, you can fire an event every time an update/insert/delete happens that will refresh the table.
If another process can make changes to the database then you'll need a background thread that will occasionally query the database for changes.
In terms of displaying the data in the JTable, you'll probably need a pretty customized TableModel to cache data, etc.. to minimize the effects of refreshing if the data is changing rather frequently
Related
At the moment, I have a little JavaFX app that generates reports and statistics from the data on a remote MySQL-Server. I use EclipseLink for persistence. Since the access is read-only and the data doesn´t always need to be fresh, I thought I could speed things up by using an embedded DB (H2) that can be synchronized to the remote server when and if the user wishes to. The problem is, I don´t have a clue how to go about it.
What I came up with so far, is to execute mysqldump, make a dump of the remote server and execute the resulting SQL script locally. This is surely far from elegant, so: Is there a patent solution for this task?
Well, 50 tables possible have a considerable amount of relations, this can be tricky... As far as I know there is nothing that automate this for you or something like that. Very possible that you will have to create your own logic to that. When I did something like what are you trying to do I used the logic of "last update", like, the local data have the timestamp of the time it was last synced with the remote, and the remote data have the timestamp of the last time the data was updated there (himself on the table, or even a relation to it like a One-To-One). Having that data, every time the local user enter a part of the system that can be outdated, the client connect to the server and check if the last update timestamp is bigger that the local synced timestamp, if so, it updates the full object and relation. I consumed some time to develop but at the end worked like a charm. There may be some other way to do it, but this was the way I found at the time. Hope it helps you with your problem.
I have an issue with my app that is a stand alone Java application. I am using the core java, JDBC and javafx 2.1. I have to show users the number of rows present in a table in the database. For that I am firing SELECT COUNT(*) FROM SCHEMA.TABLENAME in my java code and displaying results in a tableView (javafx 2.1). As my database contains large number of tables with large rowcount (number of rows in a table), this process takes a lot of time (30 mins.). With that approach, my tableview is stuck and users will be unable to proceed further until the process finishes. I am using the normal Thread.sleep() in my code.
I would like to run the process in the background so that users will be able to do other tasks. Users should be notified once the process is done. I have tried with javafx 2.1 asynchronous but couldn't solve the issue.
Please give me some piece of code that will interact with the db in the background in javafx 2.1.
Thanks& Regards
Salamat
Use a Task as in the JavaFX Concurrency Tutorial.
This allows you to safely execute code on a background thread and not block the main UI thread.
Here is some sample code for accessing a database using a Task.
I have a web application based on Java EE and MYSQL.
The problem which I am facing right now is, there is an event getting fired online, which is updating a table entry for a large number of rows.
There is also a batch job scheduled in the environment, say for every 6 minutes, which is also updating the same table entry, as mentioned above.
So the situation is that, when the online event is getting fired in the time range of the batch run, the table is getting locked.
So, experts please provide your ideas, on how to prevent the lock to take place.
Looks like a design issue,take a look at using temporary tables.
Does anyone have a code sample of a multithreading case that has about 25 threads that monitor a specific table in the database for a change then execute a process based on that change?
If you just want to be notified in the client application that something has changed in the database and you need to react on that in the application itself (so that triggers are not an option) you can use Oracle's change notification.
In order to do that, you register a listener with the JDBC driver specifying the "result set" that should be monitored. That listener will be called whenever something changes in the database.
For details on how this works, see the manual:
http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/dbmgmnt.htm#CHDEJECF
If you want to monitor the table (in the database) and make changes also in the database, then you should really consider Triggers.
Simply, Triggers are kind of procedures that run automatically BEFORE or AFTER changes on a table. You can monitor UPDATE, INSERT or DELETE transactions and then make your action.
Here is Simple tutorial on Oracle Triggers
Try directly using a Database Trigger instead.
Check this question about getting events in java from Database
I am creating an android app that is basically a listing of information on Mushrooms. I get this information from an sqlite database. I have a global singleton with a services class inside it in which I use to access my db. Almost every activity accesses the db. Is it better to leave my db open all the time or open and close it as I need the data?
If the best practice is to leave it open all the time, where do I need to make sure to close it and what is the worst case scenario if I left it open when the activity was destroyed?
Your best option here is to refactor so that your application accesses the database via a ContentProvider. Your ContentProvider implementation is the only thing with a handle to the database open.
This gives you several advantages:
only one thing has the database open, so your problem just goes away.
lots of standard support classes to automate stuff like database management.
better integration with the standard Android list-management views, which are all designed to work automatically with cursors provided by ContentProviders.
All your data can be addressed by URI (typically of the form 'content://com.fnord.mushroom/mushroom/43'), which means that other applications can access your data too.
Using a ContentProvider, it's possible to glue three or four standard classes together to produce a browser interface to your database and never actually have to write any real logic.
On the negative side, ContentProviders only really support access via a limited interface --- in SQL terms, you get INSERT, SELECT, UPDATE and DELETE with no nested clauses. If you're doing complicated SQL stuff it can be a bit painful to route requests from your app to the ContentProvider and back again. However, most people don't need to do this (and if you do, custom intents are the way to go).
I would open the db as needed. That way you know for sure the connection is closed once the particular activity that opened it is finished. Although Android has built in checks to make sure it closes upon application termination, it doesnt hurt to be on the safe side. I'm also guessing having it open all the time could cause leaks or something.
Based on my past experience in Java I would say it is better to close the connection, it probably doesn't matter in a small Android application, but if you have 10 applications running and all of them access the database, you have 10 pending connections. Start a few more and sooner or later another application will have to wait because the SQL server can't handle any more requests.
I guess you could think of it as a file on your computer. You read data from it, and then close it when your done. Why keep a file open in your application?
Now I'm very new to Android programming so I haven't got around to implement database calls. But when I faced the same problem in a Java application a few years ago I implemented a database object, in which I had the connection to the database. "Everyone else" (the classes) had to call the database object (singleton or final methods) to get data, sort of like stored procedures but in the application instead.
Because of this I knew when the calls where made and when they stopped. I then put in a timeout, so as if nothing happened in a few minutes, I would close the connection to the db. (This also took care of some timeout exceptions because the timeout of the connection would never happen.) When a new call entered, I could easily start a new connection and use the new db connection.
Basically I abstracted away SQL calls by having methods as public Fungus[] getAllFungus() and public Fungus[] getFilteredFungus(string where).