| Subject | Re: [firebird-support] Re: FireBird Events |
|---|---|
| Author | David Johnson |
| Post date | 2005-07-18T02:11:52Z |
On Sun, 2005-07-17 at 21:27 +0000, sasidhardoc wrote:
triggers, either professionally or recreationally. You will notice that
I rarely comment on Firebird specific questions. I mostly offer
suggestions about generics from an enterprise scale systems perspective.
Also, as I understand it, a Commit occurs at the transaction level, so
it cannot occur within the SP or trigger.
There's a lot of ways to resolve this. The ones that are conceptually
the easiest require polling.
If you want to avoid polling, then you may want to write a UDF that
multicasts on UDP across a socket on every insert. If this solution is
chosen, the client piece will need a UDP monitor thread to run in the
background, receive messages and test them (am I subscribed to this
message), then post them through a Queue (TQueue in Delphi) or an event
to the GUI thread.
Another related option is to track subscriptions on the server side, and
individually transmit a TCP packet to each client machine that is
subscribed to a topic. The bulk of the complex code would be identical
to the prior option. The biggest difference is that there would be
potentially more network traffic, but no need to identify at the client
whether or not the client was subscribed - a packet can only be
transmitted if you are subscribed.
Since you are talking about a small installation, either mechanism would
probably be just about equally efficient.
> > Are you saying you want the database to PUSH data to the clients?No problem. My word on Firebird isn't gospel - and I rarely use SP's or
> DBMS'
> > don't work that way - they are a pull only architecture.
> David,
> I suspect I do not have nearly the experience you do - so please
> forgive any ignorance...
triggers, either professionally or recreationally. You will notice that
I rarely comment on Firebird specific questions. I mostly offer
suggestions about generics from an enterprise scale systems perspective.
> POST_EVENT can be declared inside a Stored Procedure. POST_EVENT canPOST_EVENT is strictly within the DBMS, so far as I understand it.
> also take input variable: So, inside an SP, and after COMMIT
> POST_EVENT :STOCK_ID
> should notify any client that has subscribed to EventName = :STOCK_ID
> So, in this instance the DB is 'pushing' info to the client. (or, am I
> way of the mark here?)
Also, as I understand it, a Commit occurs at the transaction level, so
it cannot occur within the SP or trigger.
There's a lot of ways to resolve this. The ones that are conceptually
the easiest require polling.
If you want to avoid polling, then you may want to write a UDF that
multicasts on UDP across a socket on every insert. If this solution is
chosen, the client piece will need a UDP monitor thread to run in the
background, receive messages and test them (am I subscribed to this
message), then post them through a Queue (TQueue in Delphi) or an event
to the GUI thread.
Another related option is to track subscriptions on the server side, and
individually transmit a TCP packet to each client machine that is
subscribed to a topic. The bulk of the complex code would be identical
to the prior option. The biggest difference is that there would be
potentially more network traffic, but no need to identify at the client
whether or not the client was subscribed - a packet can only be
transmitted if you are subscribed.
Since you are talking about a small installation, either mechanism would
probably be just about equally efficient.
> Is someone using Events in this manner??
> TIA