On Mar 7, 4:44 pm, "David Crawshaw" <[EMAIL PROTECTED]> wrote:
> > It would be great to see a fix for this in the next release David or
> > an explanation as to why it doesn't work.
>
> You're using programs I have no experience with and I do not have the
> time to learn. But I can guess:
>
> SQLite does not support concurrent writes.
>
> You can do this with server-based DBMSs (such as MySQL, PostgreSQL, MS
> SQL, Oracle, etc);
>
> rs = conn1.prepareStatement("select * from x;").executeQuery();
> rs.next();
> conn2.prepareStatement("insert into y ...").executeUpdate();
>
> You cannot do this with SQLite. The thread with conn2 will block until
> conn1 closes its select statement. If more than 3000ms passes, conn2
> will throw a "db is locked". Sloppy code leaves selects open for the
> long term in some threads, because they're used to a DBMS do the dirty
> work for them. I suspect that is what is happening here. When someone
> is writing to the file, no-one can be reading it.
>
> d.
Is there a way to increase the timeout period before the exception is
thrown? Better yet, can the timeout be disabled and block
indefinitely? Is there some other reason why the operations requiring
the locks timeout other than as a way to notify the programmer of a
possible (likely) error in their JDBC resource handling?
I have this exact situation happening and I'm finding myself having to
catch the 'db locked' expections, sleeping and recursively calling the
method again until the read or write op succeeds.
I have a thread that runs periodically, does some work and logs the
results to the db. There is also another servlet thread, with its own
Connection to the database, that reads the log entries and displays
them to the user when the web page is requested. This thread also
writes to the log table as well (to log user activity, etc.).
Everything is fine except in the case where a user requests to view
the log at about the same time as the worker thread starts an
iteration of its own. In this particular case one of the threads will
(usually) end up throwing an exception since the worker thread, on
average, takes between 2-5 seconds to complete its task.
My ideal solution would be to have an option to disable the timeout
and just have the operations block indefinitely. If a deadlock occurs
then I'll take the responsibility of debugging my code to eliminate
the deadlock. Of course, I'm assuming that there are no other reasons
why the timeouts are in place to begin with. If the timeouts must
exist for some other reason then an option to increase the timeout
would be the next best thing. For example, in my case a timeout of 10
seconds should always be more than enough time for locks to be
released, whereas 3 seconds really isn't.
- Derek
--~--~---------~--~----~------------~-------~--~----~
Mailing List: http://groups.google.com/group/sqlitejdbc?hl=en
To unsubscribe, send email to [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---
