I have a web application which is based on SQL Server 2012, and I use Java to update data in the database. (Windows Server 2008, JSP, Tomcat7, Java7)
The relevant code is as follows:
public static synchronized int execute(String dsName, String packageAndFunction, List fields) {
// prepare insertStr
String executeStr = buildStatement(dsName, packageAndFunction, null, fields);
dbConn = DBConnection.getInstance();
Connection conn = dbConn.getConnection();
CallableStatement stmt = null;
int result = RESULT_FAILED;
try {
stmt = conn.prepareCall(executeStr);
// fill statement parameters (each ?)
fillStatement(stmt, fields);
stmt.execute();
result = stmt.getInt(fields.size());
} catch(SQLException e) {
Log.getInstance().write("Exception on executeGeneral (" + packageAndFunction + ") " + e.toString());
} finally {
try {
stmt.close();
dbConn.returnConnection(conn);
} catch(SQLException e) {
Log.getInstance().write("Exception on executeGeneral (" + packageAndFunction + ") " + e.toString());
}
}
return result;
}
About 90% of the time, the code works great. The rest of the time there is some kind of lock on the table which will disappear by itself in perhaps half an hour or so. The lock prevents even simple SELECT queries on the table from executing (in SQL Server Management Studio). In severe cases it has prevented the entire application from working.
I had an idea to use stmt.executeUpdate() instead of stmt.execute(), but I have tried to research this and I do not see any evidence that using stmt.execute() for updating causes locks.
Can anyone help?
Thanks!
It's difficult to diagnose with that code. The next time that it happens, pull up your activity monitor on the SQL server and see what sql command is holding the lock.
Related
I am writing an plugin for a online game. It is running on a MS Server 2012. The plugin works by extending #EventMethods provided by the developers API and my Plugin uses a SQLite database for storing player information in relation to the games "chunks" (3D spaces within the environment).
Everything had gone fine on my test server, but I only had myself and one other user testing it.
When I deployed the plugin to the main server and people started joining (around 12 users) the server crashed after about ten minutes with a "A fatal error has been detected by the Java Runtime Environment: EXCEPTION_ACCESS_VIOLATION"
Now it looks to me like this was caused by SQLite crashing.
Here is an example of one of my methods that access the SQLite database.
#EventMethod
public void onPlayerPlaceObject(PlayerPlaceObjectEvent event) throws SQLException {
int blockXChunk = event.getChunkPositionX();
int blockYChunk = event.getChunkPositionY();
int blockZChunk = event.getChunkPositionZ();
String blockChunkID = "" + blockXChunk + blockYChunk + blockZChunk;
try {
//get the playerUID and the blockchunkID
ResultSet rs = database.executeQuery("SELECT * FROM `Areas` WHERE `PlayerUID` = '" + event.getPlayer().getUID() + "' AND `AreaID` = '" + blockChunkID + "'");
if (rs.next() ) {
//player owns chunk do whatever you like!
rs.close();
return;
} rs.close();
//lets see if the blockChunk event is happening somewhere where someone own ths AreaID
rs = database.executeQuery("SELECT * FROM `Areas` WHERE `AreaID` = '" + blockChunkID + "'" );
if (rs.next() ) {
//chunk is owned by someone and its not the one making the event.
String string = (String)rs.getString("PlayerUID");
rs.close();
rs = database.executeQuery("SELECT * FROM `Friends` WHERE `OwnerUID` = '" + string + "' AND `FriendUID` = '" + event.getPlayer().getUID() + "'" );
if (rs.next() ) {
//player is a friend of the owner do whatever you like!
rs.close();
return;
} rs.close();
event.setCancelled(true);
return;
} else { rs.close(); }
} catch ( Exception e ){ System.out.println(); }
}
I suspect that these methods, being called so often on the SQLite database is causing it to crash. Can someone please help me find a safer way to access this data? Or would I be better off using a "proper" database like MySQL and would that have structure in place to stop the EXCEPTION_ACCESS_VIOLATION ?
Edit: I have removed the reused ResultSet objects in the preceding code (naming the objects rs, rs2, rs3, etc.) but the Java Runtime Environment is still crashing with an EXCEPTION_ACCESS_VIOLATION on an apparent random basis (I added println statements throughout the code hoping to track down where the crash was occurring - but it indeed appears random). Sometimes the server will run for 10 minutes and crash, other times it will run for 24 hours or so and then crash. I also enclosed all of the ResultSets within try-with-resources blocks. With the same outcome.
Don't reuse the ResultSet object rs for several queries, create a new instance for each query to avoid problems.
I am trying to add records to a table in an HSQL database through Java.
I have an HSQL database I made through OpenOffice, renamed the .odb file to .zip and extracted the SCRIPT and PROPERTIES files (It has no data in it at the moment) to a folder "\database" in my java project folder.
The table looks like this in the SCRIPT file
CREATE CACHED TABLE PUBLIC."Season"("SeasonID" INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY,"Year" VARCHAR(50))
All fine so far, the database connects just fine in Java with this code:
public void connect(){
try{
String dbName = "database\\db";
con = DriverManager.getConnection("jdbc:hsqldb:file:" + dbName, // filenames prefix
"sa", // user
""); // pass
}catch (Exception e){
e.printStackTrace();
}
}
I have the following code to insert a record into "Season".
public void addSeason(String year){
int result = 0;
try {
stmt = con.createStatement();
result = stmt.executeUpdate("INSERT INTO \"Season\"(\"Year\") VALUES ('" + year + "')");
con.commit();
stmt.close();
}catch (Exception e) {
e.printStackTrace();
}
System.out.println(result + " rows affected");
}
I have a final function called printTables():
private void printTables(){
try {
stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM \"Season\"");
System.out.println("SeasonID\tYear");
while(rs.next()){
System.out.println(rs.getInt("SeasonID") + "\t\t" + rs.getString("Year"));
}
}catch (Exception e) {
e.printStackTrace(System.out);
}
}
Now if I run this sequence of functions:
connect();
printTables();
addSeason("2010");
printTables();
I get this output:
SeasonID Year
1 rows affected
SeasonID Year
0 2010
Now when I close the program and start it again I get exactly the same output. So the change made during the first run hasn't been saved to the database. Is there something I'm missing?
It's caused by write delay params in hsqldb, by default has 500ms delay synch from memory to files.
So problem is solved when it's set to false
statement.execute("SET FILES WRITE DELAY FALSE");
or set as you like based on your app behaviour.
So my workaround is to close the connection after every update, then open a new connection any time I want to do something else.
This is pretty unsatisfactory and i'm sure it will cause problems later on if I want to perform queries mid-update. Also it's a time waster.
If I could find a way to ensure that con.close() was called whenever the program was killed that would be fine...
I've tried most of the examples found here and the web, but I can't open a MS access database(2002 or 2013) and get an updatable result set using UCanAccess. The same code using the JDBC:ODBC driver/connection/works. I've written short test code to check concur_updatable to check this, so I must be missing something. I'm using JDK 1.7 on a Win7 machine. I also have another machine with the same results.
This works:
/*
class jdbc, for testing jdbc:odbc CONCUR_UPDATABLE.
*/
import java.sql.*;
public class jdbc {
private static String dbFQN;
public static void main(String[] args) {
try {
dbFQN = ("C:\\phil\\programming\\kpjl2002.mdb");
String database = "jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=" + dbFQN;
System.out.println("Loading database: " + database);
Connection conn = DriverManager.getConnection(database, "", "");
Statement s = conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
// Fetch records from table
String selTable = "SELECT * FROM " + "tblLibrary" + " ORDER BY Artist, Cat, Cart";
s.execute(selTable);
ResultSet rs = s.getResultSet();
int concurrency = rs.getConcurrency();
if(concurrency == ResultSet.CONCUR_UPDATABLE)
{
System.out.println("rs is updatable");
} else {
System.out.println("rs Not updatable");
}
s.close();
conn.close();
} //close try
catch (Exception ex) {
ex.printStackTrace();
} //close catch
} //close main method
} //close dbAccess class
The output is that rs is updatable.
This doesn't work:
/*
class ucan, for testing ucanaccess CONCUR_UPDATABLE.
C:\jdk1.7.0_79\jre\lib\ext\ucanaccess-2.0.9.5.jar
C:\jdk1.7.0_79\jre\lib\ext\hsqldb.jar
C:\jdk1.7.0_79\jre\lib\ext\jackcess-2.1.0.jar
C:\jdk1.7.0_79\jre\lib\ext\commons-lang-2.6.jar
C:\jdk1.7.0_79\jre\lib\ext\commons-logging-1.1.1.jar
also present:
C:\jdk1.7.0_79\jre\lib\ext\commons-logging-1.2.jar
C:\jdk1.7.0_79\jre\lib\ext\commons-lang3-3.4.jar
*/
import java.sql.*;
public class ucan {
private static String dbFQN;
public static void main(String[] args) {
try {
dbFQN = ("C:\\phil\\programming\\kpjl2002.mdb");
String database = "jdbc:ucanaccess://" + dbFQN;
System.out.println("Loading database: " + database);
Connection conn = DriverManager.getConnection(database, "", "");
Statement s = conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
// Fetch records from table
String selTable = "SELECT * FROM " + "tblLibrary" + " ORDER BY Artist, Cat, Cart";
s.execute(selTable);
ResultSet rs = s.getResultSet();
int concurrency = rs.getConcurrency();
if(concurrency == ResultSet.CONCUR_UPDATABLE)
{
System.out.println("rs is updatable");
} else {
System.out.println("rs Not updatable");
}
s.close();
conn.close();
} //close try
catch (Exception ex) {
ex.printStackTrace();
} //close catch
} //close main method
} //close dbAccess class
the output is that rs is Not updatable. So I cannot update or insert rows in the resultset.
The code posted is the operative part of a larger project, where UCanAccess can read the table and put the contents in a jList and jTextarea, with formatting. When I started writing code to update or add a new record, I ran into the problem.
I apologize if this is a bit long.
Anybody have an idea what I'm missing or doing wrong?
BTW, this is one of my 2 fav sites for good, usable Java answers.
UPDATE:
Got an idea from old co-worker, the original database may have been copied from an original Access97 db. to a 2000 db. I had used 2013 Repair and Compact to make "new" 2002 and 2013 db's. Access must retain '97 type even when doing what I did. So, I created a new 2013 dummy db to test, and UCanAccess will report resultset as updatable. I will try to recreate the record data of the current db in a new database file, and see if that works. I'm hoping this is the problem, since UCanAccess doesn't support updatability with Access97 db's. I'll let ya'll know what I find.
Thanks.
I had used 2013 Repair and Compact to make "new" 2002 and 2013 db's. Access must retain '97 type even when doing what I did. So, I created a new 2013 dummy db to test, and UCanAccess will report resultset as updatable.
The "Compact and Repair Database" feature in Access does not change the database file version. If you have (what you suspect to be) an older-version database file then you should use the "Save Database As" feature under "File > Save & Publish" * to convert the database file to a newer version.
* (... at least that's where it is in Access 2010.)
Well, after a nice weekend of eating brats and drinking good beer at Germanfest, I finally got things working. I decided to scrap the MS Access db and put the 472 records in a SQLite db. With that, I was able to get PreparedStatements to work to display the records in a jList and JTextArea, add a new record and update a couple fields in an existing record within the same run of the test application. Did it both as a command line run GUI and from NetBeans 8.0, so I think my problems are solved. After a couple of summer projects get done, I'll get back to re-writing the original VB app using Java.
Thanks Gord, and everyone here.
I'm connecting to an Access database with a jdbc:odbc bridge.
I then select a large amount of data from the database (~2 million rows).
The first time I run the code after a restart it is very slow, taking over 6 minutes to retrieve the data.
On subsequent runs, it takes only 1.5 mins to do the same thing.
This is the code I'm using to connect to the database:
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
String url = "jdbc:odbc:Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=" + databaseLocation + databaseName + ";selectMethod=cursor; READONLY=true; TYPE=FASTLOAD";
con = DriverManager.getConnection(url);
System.out.println("Connected to " + databaseName);
} catch (SQLException e) {
System.out.println("SQL Exception: " + e.toString());
} catch (ClassNotFoundException cE) {
System.out.println("Class Not Found Exception: " + cE.toString());
}
After much Googling I've tried adding parameters such as
selectMethod=cursor
READONLY=true
TYPE=FASTLOAD
As far as I can see, none of these made a difference.
I then select the data like so:
String SQL = "SELECT ADDRESS_MODEL.ADDR_LINE_1, ADDRESS_MODEL.ADDR_LINE_2, LOCALITIES.NAME, ADDRESS_MODEL.SECONDARY_LOCALITY, TLANDS.NAME, ADDRESS_MODEL.POST_TOWN, ADDRESS_MODEL.COUNTY FROM ((ADDRESS_MODEL LEFT JOIN BUILDINGS ON ADDRESS_MODEL.BUILDING_ID = BUILDINGS.BUILDING_ID) LEFT JOIN LOCALITIES ON BUILDINGS.LOCALITY_ID = LOCALITIES.LOCALITY_ID) LEFT JOIN TLANDS ON BUILDINGS.TLAND_ID = TLANDS.TLAND_ID WHERE BUILDINGS.COUNTY_ID = " + county_ID;
PreparedStatement prest = con.prepareStatement(SQL);
ResultSet result = prest.executeQuery();
I tried using a prepared statement but I'm not sure I did it right.
After storing the data I close the ResultSet:
result.close();
Later in the program, I close the connection as follows:
try{
stmt.close();
con.close();
System.out.println("Connection to " + databaseName + " closed");
} catch (SQLException e) {
System.out.println("SQL Exception: " + e.toString());
}
Unfortunately I am committed to using both Java and Access at this point.
Does anyone have any idea why it is slower the first time (or more why it is faster on subsequent runs)?
Also, are there any general things I could do better to make it faster?
Thanks for your time.
You say two million rows, but how large is the data? It's quite possible that it's reading it all in from disk the first time, then it's in the disk cache for subsequent runs. Even if the entire dataset doesn't fit in RAM at once, it's likely that key data structures will still be present.
I am new to Derby and to databases in general for that matter. How can I create a prepared statment for an embedded derby database? Im not sure because the database is embedded.
My String is:
final String updateString = "create table " + TABLE_NAME_TBL_IPS + " (" +
TABLE_COLUMN_COMPANY + " " + TABLE_COLUMN_COMPANY_DATA_TYPE+ "," +
TABLE_COLUMN_IP + " " + TABLE_COLUMN_IP_DATA_TYPE + ")";
Also what is the benefit of using this as a stored procedure instead of a prepared statement call?
It doesn't really matter if the database is embedded or not, as long as it has JDBC connectivity. In your case, Derby does provide you to the connection information.
Your code may look something like this:-
// much easier to read with String.format()... in my opinion
final String updateString = String.format("create table %s (%s %s, %s %s)",
TABLE_NAME_TBL_IPS,
TABLE_COLUMN_COMPANY,
TABLE_COLUMN_COMPANY_DATA_TYPE,
TABLE_COLUMN_IP,
TABLE_COLUMN_IP_DATA_TYPE);
Connection con = null;
try {
con = DriverManager.getConnection("jdbc:derby:yourDatabaseName");
PreparedStatement ps = con.prepareStatement(updateString);
ps.executeUpdate();
ps.close();
}
catch (SQLException e) {
e.printStackTrace();
}
finally {
try {
con.close();
}
catch (Exception ignored) {
}
}
Regarding your question whether to do so using a stored procedure or a PreparedStatement, there are bunch of information out there you are easily search. You generally use a stored procedure to group bunch of SQL statements whereas a PreparedStatement only allows you to execute one SQL statement. It is a good idea to use stored procedures if you intend to expose that API to allow your users to execute it regardless of technology (Java, .NET, PHP). However, if you are writing this SQL statement only for your Java application to work, then it makes sense to just use PreparedStatement.