> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to