You might consider a JDBC URL convention whereby "jdbc:sqlite:shared:"
(or some better syntax) would share a single instance of the Nested runtime.
This would allow an in-memory database to be shared between different
connections (at the expense of serializing access to it).
By default, the connections would not be shared.
--- David Crawshaw <[EMAIL PROTECTED]> wrote:
Ashwin wrote:
> However, when multiple Threads retrieve a fresh Connection from the
> Driver using "jdbc:sqlite:" simultaneously, the DB instance is not
> shared, but each Thread seems to create its own instance. Could you
> confirm if this is true?
As of the current version, it is true. Each new connection using the
nestedvm driver will create a big bulky Runtime instance.
The question is, do we want to change this? While it would be easy to
have different Connections sharing a Runtime instance, it means that
all access to the Runtime instance must be synchronized. While SQLite
can handle multiple threads at once as long as they use different
database handles, NestedVM cannot.
This would be a problem for people who are trying to use a secondary
Connection to run long (like 30 second) queries on the data while not
interfering greatly in fast queries that form the standard operation
of the program. Of course, these people should be using the native
driver, which does not have this trade off and is faster, but people
like pure Java.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"SQLiteJDBC" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups-beta.google.com/group/sqlitejdbc?hl=en
-~----------~----~----~----~------~----~------~--~---
