On 27 April, Greg Carter wrote:
On 27 April 2012 11:39, Larry Brasfield <larry_brasfield at iinet.com> wrote:
[snip]
> You "works as it should" is only assured (inasmuch as any
> software can) when you use the .Net framework's assured disposition
> mechanism ("using ..." and properly implemented IDispose) or effect the
> equivalent in your own code.
>
> Yes thanks I'm familiar with using native resources from .net.
My commentary was motivated by your assertion that the fault only
occurred when you let the garbage collector dispose of your connection
object. Hence, my response was akin to the doctor who advises a patient
complaining of pain when he does X, "Don't do X". As detailed below,
there is other good reason to not do X in this case.
After much more debugging I have found what I think is a bug.
...
It's good to see this sort of thing uncovered.
> So is this intended behaviour or a bug? I can try to come up with a test
>> case that reproduces this if needed.
>
> It's not really intended behavior but intent cannot cure this problem
> unless SQLite's finalizing API is used.
>
I'm not sure I follow you. Users of System.Data.SQLite shouldn't have to
concern themselves with calling dispose.
I have to disagree with this, or be educated as to why it is true. DB
connections have always represented a hold on resources that should be
timely released, which is why IDisposable is exposed by IDbConnection.
Is there something that makes it useless to arrange that its Dispose
method is timely called rather than letting the garbage collector do so
whenever it gets around to collecting no-longer-referenced
SQLiteConnection objects?
Regardless of that, even if you
do call dispose on the SQLiteConnection instance explicitly (or through a
using statement) the underlying SQLiteConnectionHandle is added to the
pool, where it can be garbage collected before it is removed. I was wrong
when I said in my first post that this only happened when I let the
connection be implicitly garbage collected. This would appear to be a
problem with any SQLiteConnectionHandle added to the pool. I think the
only reason our code exposed this is that we had many
SQLiteConnectionHandle end up in the pool over a long period of time so the
garbage collector hand a chance to run on those SQLiteConnectionHandle.
That appears to be a fixable problem. Thanks for digging it out.
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
