> > The fact that PrepStmt references a Conn means than Conn won't be
> > finalized if PrepStmt is alive, but PrepStmt may be finalized during
> > execution of another statement, when there's no more references to it,
> > but there are references to other PrepStmt or Stmt. And this actually
> > does happen.
>
> Yeah, I see your point.
>
> I assumed that Conn also kept references to the PrepStmt instances, but it
> appears they are GC-able weak refs:
>
> public PreparedStatement prepareStatement(
> String sql, int rst, int rsc, int rsh) throws SQLException {
> checkCursor(rst, rsc, rsh);
> PrepStmt prep = new PrepStmt(this, sql);
> stmts.add(new WeakReference(prep));
> return prep;
> }
>
> Perhaps Conn could enqueue "closed" PrepStmt instances into a
> "to-be-closed" list using normal references and later serially
> invoke sqlite3_finalize on them at safe points such as in Conn.close
> and just prior to executing other statements.
This thread discusses an SML SQLite wrapper with similar issues and
ultimately a solution much like the one proposed above:
http://www.sqlite.org/cvstrac/tktview?tn=2243
This thread deals with sqlite threadsafety and is related to your
initial post:
http://www.mail-archive.com/sqlite-users%40sqlite.org/msg24843.html
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
--~--~---------~--~----~------------~-------~--~----~
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.google.com/group/sqlitejdbc?hl=en
-~----------~----~----~----~------~----~------~--~---