Re: [Firebird-devel] Red Database 2.1 released - merge ideas

[Nikolay S. <nik...@re...>]

Adriano,

Adriano dos Santos Fernandes wrote:
> Nikolay Samofatov escreveu:
>   
>> PSQL debugger for SP/triggers
>> ~~~~~~~~~~~~~~~~~~~~~
>> Proof of concept implementation, which currently uses CORBA for 
>> communication with debugger on the client side, and server-side debugger 
>> engine implemented in Java. We have discussed with Eugeny that Y-Valve 
>> can be extended to accomodate communication with debugger via the 
>> variety of supported protocols (INET, XNET, etc). Server-side Java 
>> helper on the server side becomes unnecessary in this case. We're not 
>> planning to extend it much further from what is done now, but debugger 
>> API works, in can be re-worked and polished by the community and user 
>> tools developers.
>>     
> I've very different ideas of how this feature can be made, and it worth 
> discuss benefits and drawbacks.
>
> In the client side, I'd prefer to have set of procedures and functions 
> (in a package) and debugger application controls the debugging 
> attachment by another attachment. There will be procedures and functions 
> to set breakpoints, inspect variables, etc. The debugging connection may 
> post events that the debugger could wait for.
>
> In the server side, a new debug (or notification) plugin is created, as 
> well as a DEBUG external engine used for the procedure and function 
> declarations.
>
> It allows to use the existing infrastructure (SQL, PSQL, events) and 
> allow easy use from applications (debuggers).
>   
Yes, Andriano, this is the architecture (minus packages) we discussed 
with Eugeny Putilin as the way to go for the future.

You do not cover important topic though. How debugger can execute 
queries in the context of attachment/transaction being debugged?
Especially if you factor in multi-process multi-threaded nature of V3 
engine?

In my previous letter by "extending Y-Valve to accomodate communication 
with debugger" I meant the following.

- you set breakpoints via calling ESP from main debugger attachment

execute procedure rdb$set_breakpoint ('<object_name>', <line>, ...);

- when debugger receives event that breakpoint hits it can query 
"breakpoint hits" virtual table (or ESP) in main debugger attachment

e.g.

rdb$breakpoint_hits (
  rdb$breakpoint_id,
  rdb$attachment_id,
  rdb$transaction_id,
  rdb$datetime_hit,
  ...
)

- note that breakpoints may hit multiple times in different 
attachments/transactions on a live server

- 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.

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.

These ideas are also cluster-friendly (you can have listener on one 
host, and worker process on another).

The same Y-Valve infrastructure can be used for external engines 
residing in separate processes ("ESP sandboxes") to communicate with the 
engine worker processes.

Please let me know if you need any further clarification.

> Adriano
>   
-- 
Nikolay Samofatov, MBA
Red Soft International
+1 416 710 6854