Bill,

Good suggestion for implementation.

Being that events are not dispatched until the transaction is closed how
does one determine when it should be garbage collected? It isn't possible to
make it such that upon fetching because there are potentially many clients
that would respond to the event.

Perhaps it could be aged off by a time factor?

Just thinking it through for a multi-user environment...

Jason Wharton
InterBase Developer Initiative
jwharton@...

InterBase will be the database of the new millennium.


-----Original Message-----
From: Bill Karwin <bill@...>
To: IB-Architect@egroups.com <IB-Architect@egroups.com>
Date: Monday, May 15, 2000 12:42 PM
Subject: [IB-Architect] Event datasets RFD

>From: "Jim Starkey" <jas@...>
>> But, please, go ahead and sketch an alternative scheme.
>
>Okay!
>
>1. Modify POST_EVENT syntax to the following:
>
> POST_EVENT '<name-string>'
> [ SET <identifier> = <expression> [, <identifier> = <expression> ...] ]
>
>This syntax is similar to that of the SQL UPDATE statement.
>
>2. The engine treats this as if a query had generated a result set of one
>row. It keeps an XSQLVAR structure around to contain the values posted

with

>the event. The datatypes of the XSQLVAR are determined implicitly by the
>types of expressions that the POST_EVENT passed.
>
>3. Any client that was waiting for the event must call isc_dsql_fetch() to
>get the return data. The statement handle that the client uses for this
>purpose is returned by a new API function isc_event_dataset(const char
>*event). For example:
>
> isc_stmt_handle st = isc_event_dataset("STOCK");
> status = isc_dsql_fetch(status_vector, &st, 1, &out_xsqlda);
>
>The server provides the mapping between string names of events and fake
>statement handles, to allow the fetch to work.
>
>4. If there is no associated data for the event, isc_dsql_fetch() returns
>100, just like any other result set. If the event was posted multiple
>times, there are multiple rows of data available for the given event name.
>isc_dsql_fetch() returns 0 in this case, indicating that there are more

rows

>in the result set.
>
>Issues:
>
>o It takes time to fetch these result sets, does this mean the data are
>stale? It depends on the nature of the data. One could imagine an
>asynchronous "queued" event mechanism, where you connect to the database

and

>get all the events that occurred while you were disconnected. It would be
>no worse than that. The application designer would have to keep this in
>mind, and not assume that the data returned by the event corresponds to
>committed data in the database.
>
>o Are rows of the dataset ordered in chronological order? Not by

guarantee.

>If this is important, the post_event should pass some extra data like a
>timestamp or a gen_id() value.
>
>o How long does the server keep the event's dataset around? The server
>knows which clients have registered an interest in the named event. If all
>clients have either fetched the data or disconnected, then the server can
>discard the dataset. I assume there is a similar policy currently in the
>server for expiring conventional datasets.
>
>o Can Event-datasets include Blobs? No, only data that can be stored in

the

>XSQLVAR by value can be passed through the Event mechanism. Nothing that
>requires reading other database pages is allowed.
>
>o Is there a cursor or an RDB$DB_KEY for an Event dataset? No. The

dataset

>doesn't correspond to physical storage, nor can you update it.
>
>o What if I'm in a loop fetching multiple datasets because the event was
>posted multiple times, and another event is posted? ... If you're in an
>event callback, you should disable asynchronous notification, just like the
>rules for writing signal handlers. The extra event dataset could make a
>fetch return 0 when it would have returned 100. It's possible to get into

a

>race condition here, but not likely.
>
>o Does this mean I can "poll" an event dataset without having registered

for

>the event notification? Sure, but the engine won't know to keep the

dataset

>for you; it might expire it, leading to undefined results.
>
>o What about scrolling backward through the event dataset someday when we
>have scrollable cursors? No; once you've fetched a row, it's subject to
>garbage collection. Fetch operations other than "next" for the fake
>statement handles should return an error.
>
>Bill Karwin
>
>
>------------------------------------------------------------------------
>Best friends, most artistic, class clown Find 'em here:
>http://click.egroups.com/1/4054/4/_/830676/_/958419732/
>------------------------------------------------------------------------
>
>To unsubscribe from this group, send an email to:
>IB-Architect-unsubscribe@onelist.com
>
>
>