On Thursday 05 June 2003 22:28, Don Baccus wrote: > The implementation in AOLserver 4 is very, very different. The script is > executed then the ENTIRE set of namespaces and procs are saved to the > server's "tcl.script" pointer.
Argh! > One EVIL side effect of this is that some of the standard ns_* Tcl API is > implemented in Tcl, in some cases using global variables. So, for > instance, I have a test case in which the following code: The other side effect (that we've been seeing complained about lately) is related to the following in acs-tcl: 00-database-procs-oracle.tcl: global errorInfo errorCode 00-database-procs-oracle.tcl: global db_state 00-database-procs-oracle.tcl: global errorInfo errorCode 00-database-procs-oracle.tcl: global env 00-database-procs-oracle.tcl: global env 00-database-procs-postgresql.tcl: global errorInfo errorCode 00-database-procs-postgresql.tcl: global errorInfo errorCode 00-database-procs-postgresql.tcl: global db_state 00-database-procs-postgresql.tcl: global errorInfo errorCode 00-database-procs-postgresql.tcl: global tcl_platform 00-database-procs-postgresql.tcl: global errorCode 00-database-procs.tcl: global db_state 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global db_state 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global db_state 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global errorInfo errorCode 00-database-procs.tcl: global db_state 00-database-procs.tcl: global db_state 00-database-procs.tcl:# global db_state(handles) is a list of handles that have been allocated. 00-database-procs.tcl:# global db_state(n_handles_used) is the number of handles in this list that are Methinks this could have bad side-effects, particularly if a thread without a pool and without handles executes ns_eval. The next invocation of any of the db_* API could produce the uninitialized pool result 'nsdb0' (I knew I remembered that from somewhere -- I've seen the nsdb0 result before when a pool wasn't properly initialized (way back when the PostgreSQL driver was being beta tested for PostgreSQL 6.2.1, and AOLserver was at 2.2)). Maybe I'm wrong, but I did trace through all of that code, and the only way I could see ns_pg_bind getting passed a table name of nsdb0 was through something external to the thread changing the global state variable 'db_state'. Now maybe I'm not grokking it correctly, but the proc 'db_with_handle' is mixing state between a global and an nsv (through a call to db_nth_pool_name, which uses the nsv 'db_available_pools'). Again, maybe I'm off-base a little, but I went through the code the other day (after Mohan's report of a driver issue, which isn't really a driver issue) and determined that the code paths in AOLserver 3.x and AOLserver 4.x for pool creation, handle availability and creation, and the various data structures between the database driver, the pool API, and the handle API hadn't changed in a significant way. But this behavior of ns_eval could explain that problem, depending upon the timing of its execution, as well as where the ns_eval was used. So, when a patch for OpenACS that doesn't use ns_eval is ready, those of you who have problems with the nsdb0 stuff, if yu could please determine whether the elimination of ns_eval fixes it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
