|Subject||Re: [Firebird-Java] Responding to Firebird events|
> Roman, the existing event mechanism is part of the base platformDepends on what we want to achieve at the end. If we talk about
> and, as such, isn't a good candidate for a replaceable plugin.
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 hooksOk, this is an important excercise, and it can be done without
> would be necessary to the UDF mechanism to make a JMS implementation
answering the first question.
> At a minimum, I would think it would require:I am no longer sure that this can be called UDF. For me there is clear
> * 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.
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:
CREATE TRIGGER .... AFTER UPDATE
post_jms_event('jms/cacheTopic', 'team_changed', old.team_id);
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