Subject Re: [Firebird-Java] Responding to Firebird events
Author Roman Rokytskyy
> Roman, the existing event mechanism is part of the base platform
> and, as such, isn't a good candidate for a replaceable plugin.

Depends on what we want to achieve at the end. If we talk about
extending the current event handling mechanism, then we might also
change tha code.

> I think a better approach is to think about what extensions or hooks
> would be necessary to the UDF mechanism to make a JMS implementation
> possible.

Ok, this is an important excercise, and it can be done without
answering the first question.

> At a minimum, I would think it would require:
> * Per database instance memory
> * Notification of transaction commit, rollback, and prepare
> * Notification of upcoming database shutdown
> There are probably more. The goal of the exercise isn't just to
> provide the hooks for a full functionality JMS interface, but to
> also support other external communication facilties.

I am no longer sure that this can be called UDF. For me there is clear
correlation between the suggestion above and the external procedures

If we extend that concept with the transaction outcome notification
plus the database shutdown, we would get the generic server extension

Next question is whether we want to make passing the transaction ID in
which external code was called explicit or implicit. I would think of
an implicit passing, in otherwords, making the calling transaction ID
available via thread-local variable.

All this would allow creating a server plugin providing the event
notification mechanism, for example like this:

post_jms_event('jms/cacheTopic', 'team_changed', old.team_id);
broadcast_event('', 'team_changed');

Those calls can store the actual events in some table together with
transaction ID and send events when a commit notification for that
transaction is received.

Now the question is how to allow different number of parameters/named
parameters, so those who create plugins would not need to write
overloaded calls.