Dean Arnold wrote: > I'd appreciate any reviews of my current > DBIx::Threaded design as outlined at > http://www.presicient.com/dbixthrd > > I've already implemented most of it, and have begun > testing, but I'd like a bit more feedback before > I rollout RC1. If you see something thats broken, > or if something is missing, please let me know.
After reading http://www.presicient.com/dbixthrd I don't like all the explicit waiting, although I suppose it fits the explicit nature of DBI better than something more abstract. It would be possible to create a wrapper around DBIx::Threaded that would provide self-promoting result objects (see asynchronous::universal::ready) instead of necessitating all the checking. Also a way to stack up calls against an unfinished call for background completion (see asynchronous::universal::set_callback) would be good in my book. But it looks good. Another thing is the fallback when invoked in a non-threaded perl. Have you considered using the forks module instead of threads instead of falling back to fully synchronous operation? concerning the doubts about last_insert_id(), I think a last_insert_id() statement in a callback block would have to use the same connection and would execute immediately after a threaded insert, in the same thread --- connections each have their own threads, do they not? A callback queue could guarantee that an action would happen immediately after the blocking event completed, thus solving the stale last_insert_id problem. So, I'd like to see something like $id = $dbh->dbix_threaded_start($InsertStatement,{}); DBIx::Threaded->dbix_threaded_set_callback($id, sub{ $LastInsertedID = $dbh->last_inserted_id() }); as a way to be sure that the code will run immediately after outstanding request $id completes, in the same thread, with the same connection. -- David L Nicol I've got your Oz right here http://cronos.advenge.com/pc/oz/TOC.html
