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.
Related
I have this java program that reads values from a database, and uses those values in each table for creating a schedule.
I do not have a server accessible, so the database will have to be moved around from computer to computer when the program is moved. It will have about 200 tables, each one with a time, number, title, and description.
I have tried using Microsoft Access, but Java 8 just changed some setting so that the program cannot link the Access database, even though there used to be a simple way to do this.
I know about Java DB, but to my knowledge it needs a server to host the database on, same with SQL, and I do not have one to use.
My question is, which program can I use to create a client-side database that can be linked with a java program, without breaking off an arm and a leg.
Thank You for any suggestions.
I have developed an Java Swing Application with MS-SQL Server database and now i want to provide backup and restore option in my java swing application that is on click of a button it should backup the database and restore the database any possibilities of how can i do it through java. please help
Two ways to do that. Backup and restore are just sql commands so you'd do them just the same as as you'd do any other bit of sql, e.g. a sql insert statement, unfortunately you need to know a fair bit about the the system to just do them, and you'll get no progress indicator. Using SQLSMO is another possibility, not sure about hitting a .net dll from java though. You could use SQLDMO (pre.net), but you'll need to install the backwards compatibility tools, and you'll give yourself an upgrade headache as DMO (while it seems to work) is not supported from SQL2012. Both have an event you can tick a progress bar on, course if the back up is fairly quick you could get away with not bothering with that.
However, some more to think about. You can backup while the system is running, but then you'd don't have a clear point where the system was at when you did.
Restore requires exclusive access and a high level of privilege, so it's not something you hand out and you need to get everybody off the databases.
And last but far from least it would be very bad, if you inadvertently restored a version of the database that no longer matched the application....
Personally I'd say the people who were authorised to do this should be able to do it without your tool. Dumbing it down, means a lot of code to make sure they don't restore a sql2000 back up from the trial you put out eight versions ago.
We did something similar back up restore code is a bout 2% of the application. For instance we do a pre-backup check, using dbcc et al, to make sure they aren't successfully backing up a corrupt db...
You can write a simple script to backup your database and invoke it from java.
You really need to put a little effort in here.
Since you can connect to the database server already and send it SQL commands, read this for backing up using TSQL.
For database restore, read this.
You need to have the appropriate permissions and access to the hardware for this to work.
I searched in google and stackoverflow for my problem, but couldn't find a good solution. Below is the description,
Our Java web application displays search results from our local database and external webservice API calls. So, the search logic should combine these results and display it in the result page. The problem is, the external API calls return the results slower than our local DB calls. Performance is crucial for our search results and the results should be live i.e. we should not cache or persist the external results in our local DB. Right now, we are spanning two threads, one for the DB call and another one for the exteral API, and combine these results and display it on the screen. But it kills the performance of our application, particularly when we call more than one external APIs.
Is there any architectural solution for this problem?
Any help would be greatly appreciated.
Thanks.
You cannot display data before you have it.
1) You can display your local data and as they come, add via ajax other data.
2) And if there are repeated questions, you could cache external answers for short time (and display them with warning that they are old and that they will be replaced by fresh answer) and as soon as fresh anwer arrive, push new answer.
With at least 1), system will be responsive, with 2) usable answer can be available imediately, even if its not current.
btw, if external source take long to answer, are you sure that their answer is not stale (eg. if they gather some data and wait for rest, then what they gathered so far can go stale)? So maybe (and maybe not) short term persisting is not as bad as you think.
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).
Problem solved: Thanks guys, see my answer below.
I have a website running in Tomcat 5.5 hooked up to a MySQL5 database using Hibernate3.
One record simply refuses to keep any changes performed on it. If I change the record programmatically, the values revert back to what they were previously.
If I manually modify the record in the database, the values will revert (seemingly once the webapp accesses them).
I have tried stopping Tomcat and changing the values manually then starting Tomcat again. Checking the database, the values remain changed after Tomcat has started the webapp but will revert back again once I load the site.
I have also tried deleting the Tomcat work folder for the webapp and the .ser cache file.
I have also checked the code for the values that are being reverted to and cannot find them.
I have only noticed it on this one particular record.
Edit: I've just had a look at the SQL output from Hibernate using hibernate.show_sql=true. There is an update query logged for the table my row is in. Does anyone know how to resolve the ? for the columns to actual values?
You could temporarily enable the mysql query logging and see exactly what sql statement altered the value. Since you say it changes immediately after the server starts you should be able to figure out the statement pretty quickly.
http://dev.mysql.com/doc/refman/5.0/en/query-log.html
To answer your question:
Does anyone know how to resolve the ?
for the columns to actual values?
You can do this with p6spy. Instructions for how to set this up in a Spring app are available here.
However, I think there's a mistake in these instructions, the file they refer to as p6spy.log should actually be name p6spy.properties.
It's getting close to halloween, so you have to expect this sort of thing (plus it was just a full moon), but I'd keep looking for the culprit in the web application ... it HAS to be there. A couple values I'd immediately search for in the webapp source code:
The id of the record being changed.
The value that's being written into
the record.
Good luck ... these can be real bears to find!
This smells a little like a test-case firing on start up that modifies the row to what it expects it to be before testing.
Add a trigger BEFORE UPDATE, check row id, raise an SQL error if it matches your magic row.
Then check the generated stacktrace, walk the code and locate the piece that updates the row.
Thanks to everyone for the help. All of the suggestions came in handy for tracking it down.
I've managed to find out what was causing it. Bad database design, multiple data models and Hibernate makes for some nasty stuff. Another table had the value stored and that class was extending a base class with the same value.
Time to look at doing some normalisation.