in reply to Re^10: threads::shared seems to kill performance (Workaround).
in thread threads::shared seems to kill performance
There I can't get that :memory: to work with ?cache=shared, so it always uses a file in the end.
You need to read the sqlite docs I linked above :)
It is:
(But that has this anomalous problem with the undeleted file. Leastwise, under Windows.)
I get this with your latest code:-rw-r--r-- 1 19456 Jul 24 22:46 file:memdb2?mode=memory&cache=shared
That's interesting. And it may explain the problem under windows.
I was expecting that the uri syntax 'dbi:SQLite:dbname=memdb2?...' would create a file called (just) memdb2.
Ie. That the file: bit was just the URI scheme (equiv. to http:). But it seems that it is being taken as a part of the filename to be used for the db.
Which explains the problem with Windows in as much as Windows uses the syntax filename:streamname to access its Alternate File Streams.
I've also tried all of these different URIs, ...
In order to use your existing file from multiple threads (via multipe connects) you do need to use the URI-form of the connect.
Say your existing file is in the current directory, and is called 'mysqlite.db'; then (I think) you should use the connect string:
CONNECT=> 'dbi:SQLite:dbname=file:mysqlite.db?cache=shared'
If it is in some other place then:
CONNECT=> 'dbi:SQLite:dbname=file:/path/to/mysqlite.db?cache=share +d'
I can't verify this at the moment, so see how you get on with that. (And read the docs to see if you agree with me.)
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^12: threads::shared seems to kill performance (Workaround).
by Jacobs (Novice) on Jul 24, 2013 at 22:46 UTC | |
by BrowserUk (Patriarch) on Jul 24, 2013 at 22:54 UTC | |
by Jacobs (Novice) on Jul 25, 2013 at 06:23 UTC | |
by BrowserUk (Patriarch) on Jul 25, 2013 at 06:46 UTC | |
by Jacobs (Novice) on Jul 25, 2013 at 12:22 UTC |