by Paul Reeves
The event parameter buffer (EBP) is documented as being limited to fifteen events. A question from a client prompted us to investigate this limit. It would seem from the code that the limit no longer applies in recent versions of Firebird (2.5.x, 3.x).
Vlad Horsun notes the following limits that DO exist in the current code base:
- event name length is stored in EPB using one byte, thus each event name is limited to a total of 255 bytes
- The whole EPB length must be less than MAX_USHORT, i.e. <= 65535 bytes.
- 1 byte for the EPB Version Number
- Each registered event may be allocated up to 260 bytes.
- 1 byte stores the length of the event name.
- 255 bytes for the name itself
- 4 bytes for the event counter.
This means that a single EPB can contain 252 events of event names with names of 255 bytes. Obviously with shorter event names this limit could be much higher.
As Vlad comments "If I have not missed something, up to 252 events per EPB should work at least in V2.5 and later versions."
So for all practical purposes it would appear that there is not a pre-defined limit on the number of events that we can register in a single event parameter buffer.
Does this mean we can forget the documented limit of 15 events? Maybe and maybe not. To take the extreme case - 252 events each with names of 255 bytes means that every time an event fires a 64KB EPB must be sent to every single event listener. This would be broken into several smaller packets for network transmission. On a busy system this would risk saturating an already overloaded network. And every listener must then parse every single event in the EPB to find out which event or events have just fired.
Obviously that is an extreme case. However the cost of sending the EPB across the network should be born in mind. Best practice, in a situation where a lot of events need to be registered would be to group them such that if events EVENT_A to EVENT_H are likely to fire within the same transaction that they should be registered in the same EPB while events EVENT_M to EVENT_T might be in another EPB. The network load will be reduced and the listener will also find it easier to parse the EPB.
As is often the case in life, just because you can do something doesn't mean that you should.