Roman Rokytskyy wrote:

>Why did I write that all above?
>
>First of all, I want to show that event implementation is Firebird is
>functionally a subset of JMS functionality (topics with transactional
>message sending and auto-message acknowledgement). The only difference is
>that equal messages are sent only once.
>
>Second, I suspect that the properties described above are not unique to JMS,
>but are also available in other messaging middleware. So, maybe we should
>define an API for event handling, including a transaction notification and
>let the messaging middleware to the rest? It can do it more effectively,
>also providing a much richer functionality.
>
>

>I cannot tell that there are problems with events that current mechanism
>cannot solve, but I see the way to improve it by introducing "event manager"
>plugins that will deliver the event using the desired media. Some may use
>UDP multicast, some may use TCP unicast, others can just proxy messages to
>JMS. Idea is to let server handle data and make events management a
>pluggable thing.
>
>

Roman, the existing event mechanism is part of the base platform and, as
such, isn't a good candidate for a replaceable plugin. 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. 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 suggest we move the discussion to the Architecture list.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376