Subject Re: [Firebird-Architect] Re: [Firebird-Java] Responding to Firebird events
Author Jim Starkey
Roman Rokytskyy wrote:

>>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
>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
I'm not at all sure where the line between UDFs and external procedures
is or should be. Clearly the existing UDF mechanism is too impoverished
to handle commit/rollback callbacks, so there is significant work to be
done. The real question is whether extended UDFs and external
procedures are two things or one thing. I like fewer, better things, so
I'm up for convincing you that you should design a UDF mechanism
sufficiently strong to handle both and more.

>If we extend that concept with the transaction outcome notification
>plus the database shutdown, we would get the generic server extension
I prefer to call it generic engine extension. A server is something
that talks to the a network. An engine has an API and does things. A
database server has to have an engine, but an engine doesn't have to
have a server.

>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.
I don't think transaction id is at all the right level. An internal
transaction handle, sure, but lets keep the layers separate and distinct.

>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.
The environment should be flexible enough to store them in a table or
stash them in memory or send them on a round trip to Tierra del Fuego
(IP is the temporary storage of last resort).

>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.
Oh, lots more questions than than. Does a plugin advertise its DML
name, or does it have an internal name that can be mapped by a DDL
statement? What hooks required? Is this a back door to commit time
triggers (I have 'em and love 'em to pieces)? And if not, why not?

Start with the requirements.


Jim Starkey
Netfrastructure, Inc.
978 526-1376