Subject | RE: [Firebird-Java] Re: Is EventManager of the Event API (JayBird 2.1b) thread safe? |
---|---|
Author | Rick Debay |
Post date | 2006-06-28T15:19:32Z |
Does the architecture or grammar of the Firebird Event model support
adding parameters to events?
I can picture a pair of BIGINTs being sent along the wire with the
event, and a getEventData(eventId) call to go back to the server for
more information.
The former would OR all the parameters every time the event was posted
before it was eventually broadcast to clients (like the way parameters
for asynchronous windowing messages are handled). The latter would only
work well if each event, when posted, had a unique ID associated with
it, to differentiate the first broadcast of "eventA" from the Nth
broadcast of "eventA". At the server, the programmer would be
responsible for maintaining the data structure that would be sent back
with the retrieval of the event data.
-----Original Message-----
From: Firebird-Java@yahoogroups.com
[mailto:Firebird-Java@yahoogroups.com] On Behalf Of Roman Rokytskyy
Sent: Wednesday, June 28, 2006 2:39 AM
To: Firebird-Java@yahoogroups.com
Subject: Re: [Firebird-Java] Re: Is EventManager of the Event API
(JayBird 2.1b) thread safe?
Sorry that I intervene in your discussion, just a small comment.
was changed. And I doubt it will be ever supported, since updates in a
transaction can generate tons of changes in the database and will
produce only one event. Please note that strictly speaking only one
event is fired to the each client regardless of the number the event was
fired on the server - in other words you can have event "salary changed"
but not "salary of John Smith changed". Also event is delivered to the
client *only if* the transaction that generated it was committed.
Usually, if people want to know more, they add an "audit trails" table
with an information to application about what was changed - that can be
list of primary keys or a some other custom data structure. This table
is filled in the triggers or procedures that fire the events.
Roman
------------------------ Yahoo! Groups Sponsor --------------------~-->
See what's inside the new Yahoo! Groups email.
http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
adding parameters to events?
I can picture a pair of BIGINTs being sent along the wire with the
event, and a getEventData(eventId) call to go back to the server for
more information.
The former would OR all the parameters every time the event was posted
before it was eventually broadcast to clients (like the way parameters
for asynchronous windowing messages are handled). The latter would only
work well if each event, when posted, had a unique ID associated with
it, to differentiate the first broadcast of "eventA" from the Nth
broadcast of "eventA". At the server, the programmer would be
responsible for maintaining the data structure that would be sent back
with the retrieval of the event data.
-----Original Message-----
From: Firebird-Java@yahoogroups.com
[mailto:Firebird-Java@yahoogroups.com] On Behalf Of Roman Rokytskyy
Sent: Wednesday, June 28, 2006 2:39 AM
To: Firebird-Java@yahoogroups.com
Subject: Re: [Firebird-Java] Re: Is EventManager of the Event API
(JayBird 2.1b) thread safe?
Sorry that I intervene in your discussion, just a small comment.
> The best would be to pass the changed RecordSet along the event (weThat thing is not supported by Firebird - it only tells that something
> wouldn't even need to go back to the DB to get what changed), but
> being notified is already a great step ahead.
was changed. And I doubt it will be ever supported, since updates in a
transaction can generate tons of changes in the database and will
produce only one event. Please note that strictly speaking only one
event is fired to the each client regardless of the number the event was
fired on the server - in other words you can have event "salary changed"
but not "salary of John Smith changed". Also event is delivered to the
client *only if* the transaction that generated it was committed.
Usually, if people want to know more, they add an "audit trails" table
with an information to application about what was changed - that can be
list of primary keys or a some other custom data structure. This table
is filled in the triggers or procedures that fire the events.
Roman
------------------------ Yahoo! Groups Sponsor --------------------~-->
See what's inside the new Yahoo! Groups email.
http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links