Database is locked: Is this only comes due to not finalised or close Db statements missing?.
Actually I am using db access in background as well so my some other methods can be access db at same time.
Can anyone please let me know when Database is locked and when database is busy issues comes.?
My prepared statements is execute and not an error in database but still unable to get data?
Any Help?
Database is Locked error comes when you are using the same database in some place else maybe another application by getting the lock on it and the application is still not released the lock on database.
I dont know about database is busy error. this link might answer your question SQLite Exception: SQLite Busy
Hope it somehow helps you.
The sqlite_busy can come in these cases
1. When one thread has locked a database using BEGIN and another thread is trying to write to the same database.
2. When a particular row is being updated by one thread and the same row is being read by another thread.
In both the cases install a busy handler to the database. The busy handler should attempt the execution of the statement after few milliseconds.
Related
I am using a Postgres table which gets 2000-3000 updates per second.
I am using for update this table queries generated with the update helper of pg-promise library.
Each update triggers a notify with pg_notify() function. Some nodejs scripts are handling these notifications. For some reason in Postgres logs keep appearing 'too many notifications in the NOTIFY queue' messages and also indication about the notify queue size which keep increasing up to 100%.
I read some posts like: https://postgrespro.com/list/thread-id/1557124
or https://github.com/hasura/graphql-engine/issues/6263
but I cannot find a way to debug this issue.
Which would be a good way to approach this situation?
Your listener doesn't seem to be consuming the notices fast enough, or possibly not at all. So the first step would be something like logging the processing of each notice from your app code, to figure out what is actually going on.
This might be because there is a long-running transaction that is blocking the release of older messages from the buffer. The process is explained in the manuals and is somewhat analoguous to vacuuming - old transactions need to finish in order to clean up old data.
A gotcha here is that any long-running query can hold up the cleanup; for me it was the process that was running the Listen - it was designed to just keep running forever. PG server log has a backend PID that might be the culprit, so you can look it up in pg_stat_activity and proceed from there.
I'm currenty using postgres as my database engine, which i've hooked up to a web application.
I'm have noticed on some occasions that there are locks that get accumlated in the database, mainly AccessSharedLocks (when running the query: select * from pg_locks).
One thing I have noticed is that to cancel a process that is acquiring a lock you can use pg_cancel_backend(pid), but sometime i realise that this doesnt always work!! And i'm curious to know why. Is it that this function sends a SIGINT to the database to shut it down gracefully? meaning that it wont shut it down immediately?
There is pg_terminate_backend, but i prefer to not use this.
Any advice on why pg_cancel_backend intermittently works (or at least some explanation) would be grateful).
thanks.
pg_cancel_backend and pg_terminate_backend send signals to the process.
The backend checks ever so often for pending interrupts, but it can happen that execution is in a place where it takes a while until that happens.
Canceling a query won't get rid of the locks until the transaction is closed.
I have an ASP.NET application that is using Entity Framework 6 to access data stored in an Azure SQL database. I've run into a bit of a problem connecting to the database as a whole.
If I spawn a new database instance on Azure, start my app in the debugger and step through it, I'll see that it connects without a problem, can access the seed data and all is well (inserts work without a problem, but this occurs whether I change the data or not).
However, if I restart the debugger and at all points after that attempt to connect to the database when my app restarts, the connection will fail. If I set a breakpoint and look at the Context value in the Locals window, I have the following error as the value for all DbSets:
Function evaluation disabled because a previous function evaluation
timed out. You must continue execution to reenable function
evaluation.
Despite having a try/catch around the logic, no exception will be thrown. If I step into/out of/over this, the application will just run indefinitely and never complete.
If I do a rollback to the $InitialDatabase and then re-apply the automatic migration (via update-database), I still cannot connect to the database, however if I delete the database in Azure, spin up a new one, set up the new connection information in the Web.config file and execute all over again, it'll work like a charm one time. After that, it'll fail to work again, despite no other changes to the application.
What's going on here and why is this behavior occurring? If there's an underlying problem here, how could I tell what it is and how can I resolve it?
Thanks!
After making no headway, I rolled-back to a previous version of my code from when it was working fine about three weeks back. I've updated all the logic to match what was in the latest build, I just haven't updated any of the assemblies yet. It's working perfectly fine and connecting every time now, so apparently this is the fault of one of the as-of-yet unidentified dependencies.
If I ever determine which one, I'll update this answer accordingly.
I have read a few tutorials and did some search but I must be missing something.
I've had a bunch of different problems with sqlite on my iphone app the last few days.
The most common problem was crashing when I was doing inserts at the same time on different tables, not on the same table.
I can achieve several inserts using threads by the way, so I am sure there is concurrency.
So does the db lock the whole DB or just the table I am inserting information into?
I'm also looking into another possible problems who might be causing the crashes but this little piece of information would help a lot.
After further tests I can say with certainty that you can perform multiple inserts at the same time in the database as long as it is on different tables. Multiple inserts at the same time on the same table will throw an error.
The crashes I was having earlier seem to be related to the fact that I was init + alloc the db on each view I wanted to use it and then releasing it on each view.
After init+alloc only on the app delegate it solved the crashes.
Although you can have multiple instances of the same DB throughout your App it seems to be preferable to just having one in the App Delegate and accessing it as you need it.
This might not be entirely correct but was my conclusion after several hours searching and testing.
I hope this helps other people.
There are 5 types of locks, but all are related to the whole database file and not a table-lock, or not to mention row-lock.
Are you calling sqlite3_finalize at the proper times when you're done? I've noticed that failure to call sqlite3_finalize in sqlite will pretty much bring things to a halt.
I'm new to working with iphone and SQLite i have my app working fine with SQLite but i would like to know what you all think is the correct / best way of opening an sqlite connection and closing it..
Would you
Initialise a DB connection on app load and close on app close..
Open and close connections when is needed..
Also is it good practise to constantly update db entries as you go or store all information in an object and write out at the end when needed..
There is not to much information on this via google just some useful small tutorials that cover delete / insert / update but not as a general overview of the best practise in using SQLite with iphone..
Thanks guys
Keep the connection open.
Whenever you execute a SQL query, it has to be compiled into a prepared statement. Once it's compiled, you can use it over and over and it doesn't have to be compiled again.
However, the query is compiled against the database pointer, so if you close your connection, you have to release all of your prepared statements. When you re-open your connection, you then have to re-prepare each statement as you use it again.
Save an object whenever you make a set of changes. If you are changing several things on an object (name, address, etc.) make all the changes first, then save it. Don't wait to commit several unrelated changes all at once, though (i.e. at the termination of the app). Related changes can be delayed until they are all made, before saving them.