--- TomD <[EMAIL PROTECTED]> wrote:
> On Jul 6, 4:31 am, "David Crawshaw" <[EMAIL PROTECTED]> wrote:
> > From a practical standpoint I agree, and I will definitely keep the
> > Connection thread-safe. But I'm not going to make Statement
> > thread-safe.
>
> Connection pooling in multi-threaded apps is common, and
> PreparedStatement pooling is sometimes seen.
>
> It certainly makes sense to keep Connection thread-safe. It might be
> good to do the same for PreparedStatement. There seems to be little
SQLite does not support use of a single prepared statement on multiple
threads simultaneously by design. SQLite prepared statements
(and non-prepared statements) are tied to a specific connection.
At the very least, any access would have to be synchronized with all
other activities on that connection, which results in serialized database
access for the connection anyway.
Putting the synchonization in the SQLiteJDBC statements will just
prevent crashing and producing indeterminate results if misused.
But then you run of the risk of mutex deadlock in these misuse
situations if you're not careful. Alternatively, if SQLiteJDBC could
detect multi-thread statement misuse and report it, that would also
be acceptable.
> reason to make Statement, ResultSet, etc. thread-safe because pooling
> them for use by multiple threads is an unlikely design.
>
> FYI - the JDBC 3 spec mentions Connection pooling and
> PreparedStatement pooling, but I can find no other reference (or
> inference) of thread-safety in any of the JDBC specs.
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
--~--~---------~--~----~------------~-------~--~----~
Mailing List: http://groups.google.com/group/sqlitejdbc?hl=en
To unsubscribe, send email to [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---
