Matthew Dumbleton wrote: > > I'm afraid this doesn't seem to fix the issue. >
Odd, it seemed like a disposal race condition. I thought the additional locking semantics would fix it. On the desktop versions of the .NET Framework, there is an actual CriticalHandle class and the necessary overload of the interlocked exchange method that may be used to avoid using locks during finalization. > > Just out of interest are you able to run the code I sent on a real device or in > an emulator? I'm testing on a Motorola ES400 and didn't initially think to try > switching to the emulator which doesn't seem to throw the error (still testing > though.) > I do not have a real device to test the code on. Also, the project you sent is targeted to a different emulator version than the ones I currently have available. I'll try to manually retarget the project tonight and try to reproduce the issue in more detail. > > Don't know if it's relevant but I seem to 'fix' the issue if I call a GC.Collect > before every connection to the database. But of course this could just be > because it runs slower when doing this and in any case probably not good practice. > It's relevant to the extent that the whole issue seems to be a disposal and/or finalization related race condition. Calling GC.Collect forces all 'unreachable' objects to be garbage collected immediately. -- Joe Mistachkin _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
