On Jun 26, 2014 4:06 AM, "Simon Slavin" wrote:
>
> Of course, you do get the increased time (it takes time to open and parse
the database file) and memory overhead.
One could setup a simple connection pooling mechanism in order to minimize
_open() overhead. Standard
After a little experimentation I can't find any better way of doing this than
to have each transaction handled with a different connection to the database.
In other words, for each BEGIN you need a sqlite3_open(). If you do this,
different concurrent parts of your app can each run their own
On 22 Jun 2014, at 1:56am, RSmith wrote:
> Have you incurred quite a time-penalty doing the other work (which you
> described above) in this manner, other than initial learning curve?
One method to do what I wanted is to have each task do its own sqlite3_open()
and
On 22 Jun 2014, at 1:42am, Ward Willats wrote:
> Do you mean nested transactions?
No. Two independent parts of my app without any idea that the other exists.
Perhaps one change which the user is consciously making and another monthly
processing task which is
On 2014/06/21 22:36, Simon Slavin wrote:
Hello gang.
I recently did some work with another system which supported transactions (a journaling file system) then
came back to SQLite and saw it with a different eye. In my programming for SQLite so far either each
database change has been
On Jun 21, 2014, at 1:36 PM, Simon Slavin wrote:
> But the programming style I've been using recently does the equivalent of
> allowing any number of concurrent "BEGIN"s and handing back a handle for each
> one. You can execute any number of commands (SELECT or write)
Hello gang.
I recently did some work with another system which supported transactions (a
journaling file system) then came back to SQLite and saw it with a different
eye. In my programming for SQLite so far either each database change has been
handled by a different PHP process which opened a
7 matches
Mail list logo