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

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

Adriano,

Adriano dos Santos Fernandes wrote:
> 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. 
My understanding is that the ability to set global breakpoint in some SP 
is pretty important requirement.
At the moment I don't see how it can be easily dropped or worked around.

Not always the developer can control the entire application stack, and 
connection pooling techniques popular today make identifying offending 
attachment problematic.
Thus global breakpoints are necessary.

>> 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.
>   
Yep, agree. TPB parameter is another good way.
>> 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" 
Here is the Y-Valve feature I'm talking about as it is described in 
firebird.conf:

"# Ability to redirect requests to other servers was initially present
# in Interbase, but was broken by Borland in Interbase 6.0, when
# they added SQL dialects. Request redirection was fixed in firebird 2.0,
# but today such behaviour (proxy) seems to be dangerous from security
# point of view. Imagine, you have one carefully protected firebird server,
# access to which is possible from global net. But in case when this server
# has access to your internal LAN (may and should be restricted,
# but often possible), it will work as a gateway for incoming requests like:
# firebird.your.domain.com:internal_server:/private/database.fdb
# It's enough to know name/IP of some internal server on your LAN, and for
# this connection one even need not know login/password on external server.
# Such gateway easily overrides firewall, installed to protect your LAN
# from outside attack.
#
# DO NOT ENABLE THIS OPTION UNLESS YOU REALLY KNOW WHAT YOU ARE DOING.
#
# Type: boolean
#
#Redirection = 0"

> and 
> cluster-friendly here.
>   
By cluster friendliness I mean the V3 configuration when engine runs on 
multiple hosts coordinated via DLM.
One or more listener nodes balance and redirect attachments to processor 
nodes. In this case, when debugger needs to attach to debugged 
attachment, Y-Valve at listener would redirect connection to appropriate 
processor node, but not using XNET, but some intra-cluster protocol (for 
example, INET).
> 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.
>   
I don't understand how what you propose can work for Classic and 
Embedded server (even if we leave aside other possible V3 configurations).
> Adriano
>   

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