Il 23/01/2012 16:27, Simon Slavin ha scritto:
On 23 Jan 2012, at 1:56pm, Marcello Botrugno wrote:
When I have four or more threads accessing to the database I see the error message:
"database table is locked".
This happens when a thread begins a new Transaction, probably because another
thread already has an excluse access to the database.
I supposed that, setting the "busy timeout" to an high value (30 secs in my
case) should manage this kind of problems, but probably I am wrong or I am not using
sqlite functions in the right way.
With the 30 second timeone (which, as far as I can tell, you're doing
correctly) there's no reason for you to see that.
I assume that there are no pauses between your BEGIN and COMMIT statements. In
other words, the app doesn't pause for user-input or to do lots of calculations
while you have the EXCLUSIVE lock. I also assume you are checking the result
value from all SQLite calls just in case, one of them unexpectedly returns an
error.
If possible, you might remove the word 'EXCLUSIVE'. Just to see whether the
behaviour changes in any way. I would also play with the options on the
_open_v2() call if possible, perhaps just setting SQLITE_OPEN_READWRITE, again,
just to see if anything changed.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
The problem was in the option SQLITE_OPEN_SHAREDCACHE, infact removing
that option the application works fine.
It works fine also using SQLITE_OPEN_FULLMUTEX|SQLITE_OPEN_READWRITE or
SQLITE_OPEN_READWRITE only .
Thanks again for your help.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
