We Keep Coding

How to view transaction logs in oracle of recent sql commands executed by a hibernate enabled java program (with time and performance info)

I am currently executing a java program which performs some jdbc commands like insert select etc.
My goal is to see how much time those individual commands are taking with performance impact too.
My program logs the sql commands in the seperate log file, but I need something database specific.
I want to see the performance and time taken by each command in the database view, As soon as I am finished with my program execution.
Is there any way available to achieve this? P.S. I am using Oracle SQL Developer for GUI purposes.
Any help will be appreciated. Thanks in advance.

You can use v$sql, gv$sql, dba_hist_sqltext views. Just select from this view and you will find interesting data. Filter and Sort them according to your need.
select * from v$sql;
You can join them with v$session or gv$session to fetch the session details who executed which sql.
Cheers!!

How to run querys in background thread in javafx 2.1

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.

Detecting mysql table lock from java

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.

Multithreading on a database using oracle and mysql

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

Database Access in Android

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).