I'm getting this exception of opened cursos on closing some stores on berkeley db:
Exception in thread "main" java.lang.IllegalStateException: Database still has 1 open cursors while trying to close.
at com.sleepycat.je.Database.closeInternal(Database.java:462)
at com.sleepycat.je.Database.close(Database.java:314)
at com.sleepycat.persist.impl.Store.closeDb(Store.java:1449)
at com.sleepycat.persist.impl.Store.close(Store.java:1058)
at com.sleepycat.persist.EntityStore.close(EntityStore.java:626)
This error occours "on myStore.close()":
public void close() throws DatabaseException {
myStore.close();
myDB.close();
env.close();
}
But I didn't manually open any cursor.
I've looked for this error, and I didn't find anything special I'd had to do (because I didn't open the cursor manually).
So I think I did something wrong on opening the database. What I do on opening the store:
myStore = new EntityStore(env, "StoreTest", storeConfig);
PrimaryIndex<Long, MYClass> myPrimaryIndex = myStore.getPrimaryIndex(Long.class, MyClass.class);
Again: I didn't manually open any cursor.
Any call to EntityIndex.entities() opens a cursor, whether you assign it to a variable or not. So make sure, that you assign it to an EntityCursor object, and call it's close() method afterwards, like this:
EntityCursor<Employee> cursor = primaryIndex.entities();
try {
...
} finally {
cursor.close();
}
I have had a similar problem, and this was the solution, also posted on OTN forums here:
https://forums.oracle.com/forums/thread.jspa?messageID=10241239
Related
We are using Dapper for some data access activity and are using the standard recommended approach for connecting to database as follows:
public static Func<DbConnection> ConnectionFactory = () => new SqlConnection(ConnectionString);
However, if we try and execute a statement, in the docs it show that you need to first state:
using (var conn = ConnectionFactory())
{
conn.Open();
var result = await conn.ExecuteAsync(sql, p, commandType: CommandType.StoredProcedure);
return result;
}
That means, you have to explicitly open the connection. However, if we leave out the statement conn.open(), it also works and we are worried if in such cases the connection may not be disposed of properly.
I would appreciate any comments as to how the SQL gets executed without explicitly opening any connection.
Dapper provide two ways to handle connection.
First is - Allow Dapper to handle it.
Here, you do not need to open the connection before sending it to Dapper. If input connection is not in Open state, Dapper will open it - Dapper will do the actions - Dapper will close the connection.
This will just close the connection. Open/Close is different than Dispose. So, if you really want to Dispose the connection better switch to second way.
Second is - Handle all yourself.
Here, you should explicitly create, open, close and dispose the connection yourself.
Please refer to following links for more details:
https://stackoverflow.com/a/51138718/5779732
https://stackoverflow.com/a/41054369/5779732
https://stackoverflow.com/a/40827671/5779732
Looking at the source code for Dappers QueryAsync method
SqlMapper.Async.cs
private static async Task<IEnumerable<T>> QueryAsync<T>(this IDbConnection cnn, Type effectiveType, CommandDefinition command)
{
using (var cmd = command.TrySetupAsyncCommand(cnn, info.ParamReader))
{
DbDataReader reader = null;
try
{
if (wasClosed) await cnn.TryOpenAsync(cancel).ConfigureAwait(false);
var func = tuple.Func;
if (command.Buffered)
{
var buffer = new List<T>();
var convertToType = Nullable.GetUnderlyingType(effectiveType) ?? effectiveType;
while (await reader.ReadAsync(cancel).ConfigureAwait(false))
{
object val = func(reader);
if (val == null || val is T)
{
buffer.Add((T)val);
}
else
{
buffer.Add((T)Convert.ChangeType(val, convertToType, CultureInfo.InvariantCulture));
}
}
while (await reader.NextResultAsync(cancel).ConfigureAwait(false)) { /* ignore subsequent result sets */ }
command.OnCompleted();
return buffer;
}
else
{
// can't use ReadAsync / cancellation; but this will have to do
wasClosed = false; // don't close if handing back an open reader; rely on the command-behavior
var deferred = ExecuteReaderSync<T>(reader, func, command.Parameters);
reader = null; // to prevent it being disposed before the caller gets to see it
return deferred;
}
}
finally
{
using (reader) { /* dispose if non-null */ }
if (wasClosed) cnn.Close();
}
}
}
Note this line (413):
using (var cmd = command.TrySetupAsyncCommand(cnn, info.ParamReader))
My question is, will my connection be disposed of correctly without me having to wrap my code calling in to this in a using block?
Note following line in the code you post:
private static async Task<IEnumerable<T>> QueryAsync<T>(this IDbConnection cnn,....
That shows QueryAsync is an extension method of IDbConnection. That means, instance of connection is created in your code somewhere.
As mentioned here, there are two ways to manage connection with Dapper:
Fully manage yourself:
Here, you are fully responsible for opening and closing connection. This is just like how you treat connection while working with ADO.NET.
Allow Dapper to manage it:
Dapper automatically opens the connection (if it was not opened) and closes it (if it was opened by Dapper) for you.
Considering this, only choice remain here is to open/close connection in your code or allow Dapper to do this for you. If you are doing this yourself then Dapper does not interfere at all.
If you want to allow Dapper to handle the open/close connection for you and are worried that whether it will close it properly, then yes, it closes it properly.
Find following code in your post:
if (wasClosed) await cnn.TryOpenAsync(cancel).ConfigureAwait(false);
....
if (wasClosed) cnn.Close();
Dapper maintains the state/flag in wasClosed variable if connection was opened by Dapper. You can see in your code that the connection is also properly closed at the end. Further, you can further check the Dapper source code to see how the this is handled in multiple methods. Specially check SqlMapper.Async.cs and SqlMapper.cs files.
Now, this is all about open/close. What about Dispose? Following is what Marc Gravell says in one of the comment for this answer: https://stackoverflow.com/a/12629170/5779732
well, technically open/closed is different to disposed. If you are only going to be opening/closing around the individual calls, you might as well let dapper do it. If you are opening/closing at a wider granularity (per request, for example), it would be better for your code to do it and pass an open connection to dapper.
So, if you really want to Dispose the connection instead of just open/close, better you wrap it in using block in your code and pass open connection to Dapper. As mentioned in the comment, this post discusses difference between Dispose and Close.
I'm writing an ASP.NET application. In my datalayer an sql connection is being opened and closed before and after querying. The SqlConnection is being kept as a private field of a single class. Every database call in the class uses the same structure:
conn.Open();
try
{
// database querying here
}
finally
{
conn.Close();
}
Yet, on very rare occasions I get the exception 'The connection was not closed. The connection's current state is open'. It's not possible to reproduce the problem since it originates very rarely from different parts of the code. There is some threading involved in my application but new threads also make new data layer classes and thus new connection objects.
I do not understand how it's possible to have a connection lingering around open using the code above. Shouldn't the connection always be closed after opening, making it impossible for the above exception to occur?
It's likely that an exception is being thrown in the try block that you aren't handling. See this note in MSDN for try-finally:
Within a handled exception, the associated finally block is guaranteed to be run. However, if the exception is unhandled, execution of the finally block is dependent on how the exception unwind operation is triggered.
I would recommend wrapping the connection in a using block anyway:
using (SqlConnection connection = new SqlConnection(connectionString))
{
//etc...
}
Alternatively, add a catch block to the try-finally:
conn.Open();
try
{
}
catch
{
}
finally
{
conn.Close();
}
you should close connections as soon as you operations finished. Try to open connections for the shortest time possible.
However it is best to use using it will call Dispose method even in case of exceptions.
using (SqlConnection conn= new SqlConnection(conStr))
{
//etc...
}
OR
1) Open the connection
2) Access the database
3) Close the connection
//conn.Open();
try
{
conn.Open();
//Your Code
}
finally
{
conn.Close();
conn.Dispose();//Do not call this if you want to reuse the connection
}
I'm trying to write to a local SQLite database using the flash.data.* classes in AIR. I'm opening a synchronous connection in CREATE mode and using the begin() and commit() methods to execute the queries. Everything seems to be executing as expected. The query execute() and connection commit() method's success handler is being called, the connection object's totalChanges property is being incremented, everything looks good except the database file is not being written to. Any ideas what I could be doing wrong?
I don't think it's related to...
the query itself since that was
throwing errors whenever something
didn't match up.
the file mode for the same reason.
file permissions - currently set to 777
Simplified version of the code:
var database:File = new File(File.applicationDirectory.nativePath + "//" + PATH_TO_DB );
var connection:SQLConnection = new SQLConnection();
connection.open( database, SQLMode.CREATE );
connection.begin();
var statement:SQLStatement = new SQLStatement();
statement.sqlConnection = connection;
statement.addEventListener(SQLEvent.RESULT, onQueryResult);
statement.addEventListener(SQLErrorEvent.ERROR, onQueryError);
statement.text = "INSERT INTO myCrazyTable (foo) VALUES ('bar')";
statement.execute();
connection.commit(new Responder(onCommitComplete));
function onQueryResult(event:SQLEvent):void {
trace("Query successful"); // this is getting called
}
function onQueryError(event:SQLErrorEvent):void {
trace("Error in query: " + event.error.message);
}
function onCommitComplete(event:SQLEvent):void {
trace("Commit Success"); // this is getting called
connection.close();
}
// Database isn't getting touched.
Did you check options defined by pragma? For example http://www.sqlite.org/pragma.html#pragma_synchronous can cause this behavior.
The first thing I would ask is, how do you know it isn't being touched? Timestamp? Or are you querying for the item and not finding it?
The main reason I ask is, I'm suspicious of this code:
var database:File = new File(File.applicationDirectory.nativePath + "//" + PATH_TO_DB );
I think the // is incorrect, and I think possibly your DB is ending up somewhere other than where you think it is, most likely at the root filesystem. If my theory is correct, you are writing data to a different db than you think you are, not just "in memory".
I fixed the issue. I ended up rewriting the code for accessing the database. I'm not sure exactly where the problem was, something I must have been overlooking. Thanks for everyone's help.
In using Enterprise Library, there was an issue with having to manually close db connections, as GC, when scanning the heap, looks for items out of scope.
A connection that is part of a pool that is being used but the connection state is broken or fetching, but you have already received your results, will be kept open, and connection handles in the pool will run out.
Thus, adding manual connection checking and forcedly closing the connections is good form.
Now, take SubSonic. With an EntLib base, I am doing the following in a finally block:
public static bool GetISOCountryCodes(out DataSet dsISOCountryCodes, out Response dbResponse)
{
dbResponse = new Response();
dsISOCountryCodes = new DataSet();
StoredProcedure sp = null;
try
{
sp = SPs.GetISOCountryCodes(null);
dsISOCountryCodes = sp.GetDataSet();
// set the response object properties
dbResponse = new Response((int)sp.OutputValues[0]);
return dbResponse.IsValid;
}
catch (System.Exception ex)
{
return dbResponse.IsValid;
}
finally
{
if (sp.Command != null && sp.Command.ToDbCommand().Connection != null &&
sp.Command.ToDbCommand().Connection.State == ConnectionState.Open)
sp.Command.ToDbCommand().Connection.Close();
}
}
I know it's been said that you don't have to manually do this, as SubSonic will do this for you, however, I'd like to know if anyone has run into issues with SubSonic not closing connections (once again, as it uses EntLib at the root), and if there are better ways of accomplishing this.
Obviously, in all my data caller methods, I will reference one, say, "ConnectionCloser()" method.
Thanks.
This post was more of a notification for discussion. However, I'm not sure if the issue has actually been resolved with v5. So essentially the answer is to continue checking in the finally block.