Tim, I'm curious: have you ever experimented with nonblocking OCI in your DBD::Oracle driver?
I've been using Perl Object Environment (POE) for some time now, and some projects I'd like to start require database access. As far as I'm concerned, the non-blocking workaround all existing PoCo database modules use (e.g. spawning multiple subprocesses, each with it's own database connection and a custom socket interface back to the parent process to rceive resultsets, handle errors, etc.) is somewhat clumsy, forces design limitations, and is more memory expensive than it should be. As it is, only one PoCo database module supports a database pool design, but it does not have the error handling I require for production-level applications. I would likely have to customize PoCo::LaDBI to implement the pool, and I'd much rather devote that time investment to solving the nonblocking problem at it's root rather than workarounds like this. The Oracle OCI docs specify that OCI connections can be congifured to be non-blocking, with resultsets obtained by polling OCIStmtExecute until you get a result code other than OCI_STILL_EXECUTING result. End implementors could then write their own polling logic at the perl level. This behaviour, in theory, could be added to your Oracle.pm interface by: 1. adding a new NonBlocking flag to the new constructor to specify blocking/nonblocking handle (default: blocking) 2. adding either a return code (via $DBI::err and $DBI::errstr) or eval-trappable error when OCIStmtExecute returns OCI_STILL_EXECUTING I would love to be able to implement non-blocking database access in some real-time financial processing applications I am currently developing. The scale of the applications require a database pool design to limit the number of active connections to the database backend. I've already tried prototyping an ithreads-based Database pool module with DBD::Oracle, with functional success but unreliable memory growth/leak issues. If DBD::Oracle were to implement OCI-level nonblocking handles, I could implement the entire database pool in a single process. Do you think this is a feasable task? I've only begun to review through the source of DBD::Oracle to determine the difficulty level of implementing this myself (with your guidance, if at all possible). Given the nature of the timeline requirements for the release of the applications that would depend on this functionality, I will be able to devote a signifigant amount of time to this project and start on it immediately. Let me know what you think! Sincerely, Eric Rybski
