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
Related
I may look stupid by asking this question - but i want to kill any questions that i have in my mind regarding this..
So.. the question is --
Can we abort/kill a select SQL from my grails application which is triggered from my application itself?
In layman terms -
I have 'Search' and 'Stop' buttons on my screen
Action on search button will prepare a select SQL which will take quite sometime to execute and fetch results
I want to abort long running SQL (not just application stop waiting for result. It should abort the SQL process in the background) by clicking 'Stop' button
(My DB is Oracle)
Please help me clear this trash from my mind.
You might want to use a query timeout. Grails uses Hibernate which implements JPA.
JPA2 persistence property "javax.persistence.query.timeout" allows you to set the timeout for a query (assuming the underlying JDBC driver supports it).
So add the following to the grails-app/conf/Config.groovy:
javax.persistence.query.timeout=9000
The value is in milliseconds, so that would be 9 seconds.
We have a legacy system that uses Java and an Oracle database.
I now want to set up an integration environment where we can run tests through HTTP calls.
Before the whole cycle of tests starts the database would be set up anew. We already have a functionality for this.
Now after every test only the modified data from this test should be rolled back. Is this somehow possible on an Oracle database?
If you are on Oracle 11 you can use the FLASHBACK command to restore a table to a point in time. Usage is like this
FLASHBACK TABLE employees_test
TO TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' minute);
Your user will need special privileges
SELECT ANY DICTIONARY or FLASHBACK ANY TABLE or the SELECT_CATALOG_ROLE
I assume this is for a development or test instance as these privileges are not allowed to all users on production.
Two options I see for this:
Flashback database - you can do a sort of global "rollback" of your database to a predefined restore point.
Use Datapump: when your schema is ready, export it. After each test, import it with CONTENT=DATA_ONLY and TABLE_EXISTS_ACTION=TRUNCATE (for example). Can be fairly fast, doesn't require setting things up for flashback.
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.
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
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).