From: Adriano d. S. F. <adr...@uo...> - 2008-07-21 19:16:23
|
Nikolay Samofatov escreveu: > - note that breakpoints may hit multiple times in different > attachments/transactions on a live server > I think debugger should attach to specific database sessions (i.e., one attachment). It will debug one attachment per each debug attachment. Debugging the whole server or all attachments to the database is something that not work really, I think. Debugging external procedures (in Java, for example) works in this way and it's not appropriate for a database. > - to execute queries at the breakpoint execution context (with existing > temp tables, context variables, savepoints, etc) debugger needs to > attach using the following connection string (assuming TCP is the > connection protocol) > <host_name>:<database_name_or_alias>$<attachment_id> and execute queries > in the context of this attachment. > More or less, I agree. Also, ability to connect from different process (and not always from the debugger) is great, if the debugger is not good SQL tool. Debugger just show IDs and one can connect using the preferred tool. > For this to work, when breakpoint hits worker process which handles the > attachment needs to start listening on XNET endpoint and wait for > debugger to attach. > Y-Valve "Redirection" feature can than be used to attach to this > endpoint remotely. > ... > Some sort of API (SQL command will do) will also be necessary to > impersonate a breakpoint's transaction after debugger has connected to > debugged attachment. > SET TRANSACTION may be extended so you can pass ID of existing debugging transaction. > These ideas are also cluster-friendly (you can have listener on one > host, and worker process on another). I may have not understood what you mean "Y-Valve redirection" and cluster-friendly here. For me, it should not be handled at Y-Valve, but at engine level. It catch debug connection string and associate the new attachment with the debugged attachment. Adriano |