Database events

  On Wed, 22 Feb 1995, Dwight R Coles wrote:
[snip]

> Yep, David explained that when I got more info from him that what he 
> was having was "events leakage", not rule-firing-on-rollback, which is
> what I originally thought.  The "events leakage" is subject to a SIR
> I filed about four months ago after finding the same thing.  No 
> commitment from CA to give us more control over dbevent launches
> from db-procedures yet, though.  What I requested was exactly what Noel
> suggested - an event which launches immediately (row-based event),
> and an event which pends until the complete set of rows in the transaction
> are processed (set-based event, held until commit time).

Sounds good.  What's the SIR number so I can vote on it in
Advisor?  Oh, and do you know of any way to just browse the 
SIRs on file through Advisor?  I think that'd be very interesting
reading, but all I could find is the query interface.

> Now, what do I do for a workaround?  Have the db procedure write a 
> record to a working table (I called it pending_events) for each
> row-based event you would normally raise.  Put the name of the "event"
> you would have raised in it.  Then, if you ultimately commit, you 
> release the lock you have on the table and allow a daemon process
> access to the pending_events table.  The daemon then finds, aha, 
> several events (all with same name) are here, lets send off ONE
> event to replace them all.  We save a lot of processing, loose only 
> a second or so in response time, and NEVER try to process a
> "db-event" which results from a rolled-back transaction, since the
> events from rolled-back transactions are not committed to the 
> pending_events table.

Aha!  Nice workaround.  Force the event data back into the SQL
transaction-handling rather than doing it yourself...do you have
any problems with contention on the event table?

--
Noel Maddy            noel@mail.msen.com           Work:  ncm@biostat.hfh.edu
Ingres Q & A
To William's Home Page
Email William