On Mon, Oct 14, 2002 at 02:50:45PM -0700, Henri Asseily wrote: > I've taken this off-line but if you think it's of interest to the list, > then let's switch back to the list.
The dbi-dev list is a good place for it. CC'd. > >>Basically I think Multiplex would need the following: > >>1- better implementation of timeouts, both at the connect and at the > >>execute level > >>2- better support for high-performance environments and mod_perl, > >>mostly by having a "memory state" > >> > >>Regarding (1), Multiplex still relies upon the base driver's timeout > >>system, which can hardly be relied upon. That's a pretty easy fix. > > > >Yeap. Though any timeout based on signals may leave the connection in > >an unsafe state. (But that's a generic issue.) > > I don't know how we'd do anything. However, if all it does is make the > dbh flakey, whenever it fails the HA module would just try to recreate > a new one. The timeouts shouldn't occur often. Okay. > >How can you (portably) differenciate between "badly formed SQL > >statement" > >and something like a duplicate key on insert? An application may be > >using > >insert-then-update-if-insert-fails logic. Reconnecting on each failed > >insert would work but perform very badly. > > Yep. I switched the logic to the following (which is portable): > > execute. > if fails, prepare and execute "select 1". Using $dbh->ping should be reliable and often faster. > if fails, reconnect and reexecute original sql once, otherwise do > nothing. > > This should clear up the badly formed SQL. > In a similar vein, DBD::Multiplex is really bad in the handling of > master-slave stuff (even more so than in my earlier comment below): > It attempts to figure out which statements are read-write, and makes > those applicable to the master only. That's very dangerous and > ultimately not worth much in a high-volume environment that relies > almost exclusively on stored procedures: > a regex looking for "insert" will fail on "exec p_i_save_session", for > example. Again it comes back to providing mechanisms and letting the application define policy. > True. The right hooks need to be in place for modifying Multiplex > behavior. Yeap. > >>Anyway, I'm going to dig deeper into all this and potentially make my > >>configuration structures compatible with DBD::Multiplex, which would > >>then allow for seamless use of it. By then the logic flows will > >>necessitate a supercomputer to debug... :) > >>Or of course I could take DBD::Multiplex and extend it with the logic > >>that I built. I'll let the list know my findings. I will probably > >>release the HA module first (with or without the MM functionality) and > >>then get some feedback going. > > > >As you can tell from my comments above, I'd really like to find a way > >to > >separate mechanism and policy and provide an API that DBD::Multiplex > >can offer to applications to express/implement the required policy. > > > >It could be that DBIx::HA ends up providing some pre-canned policies > >that "plug in" to DBD::Multiplex via the API. > > I agree fully. What I would suggest is: > 1- we don't do master-slave where read is on all slaves. We disable > mx_master_id behavior in Multiplex. > 2- we allow the following mx_exit_mode policies: > - read-only: > - first_success > - first_success_random > - last_result > - last_result_most_common > - read-write: > - first_success > - last_result > 3- we allow the following mx_connect_mode policies: > - report_errors > - ignore_errors_with_failover > - ignore_errors_no_failover > 4- we add the mx_failover_scope policies: > - fail_single_child > - fail_all_children > 5- we add the mx_failover_mode policies: > - stop_at_stack_end > - rollover_at_stack_end > 6- we add timeouts for each dsn: > - timeout_connect > - timeout_execute > > Now we can either implement all of those policies in Multiplex or allow > for hooks in Multiplex to do all of that. Your preference is, it seems, > to put an API on all those. I would tend to agree, except that I worry > about performance bottlenecks. I doubt they'd be significant. Much can and should be done at prepare() time rather than execute(). And much is only triggered on errors. The key, of course, is picking the right places to provide the callback mechanism and defining the right api for the callbacks. > Right now, Multiplex seems pretty inefficient and not geared towards > speed optimizations. I'll see what it will take to do all of the above. > For now, I've included my DBIx::HA.pm module as it stands, just fyi. No time to study it, sorry. But keep up the good work! Tim.
