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
>>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
>concept.
>
>

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
>mechanism.
>
>

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:
>
>CREATE TRIGGER .... AFTER UPDATE
>AS BEGIN
> ...
> post_jms_event('jms/cacheTopic', 'team_changed', old.team_id);
> broadcast_event('224.0.0.1:1234', 'team_changed');
>END
>
>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