On Monday November 1 2004 4:57, Justin Clift wrote:
> On Mon, 2004-11-01 at 10:56 -0500, Andrew Sullivan wrote:
>
> > A trigger on a sequence change is a terrible idea.  The whole reason
> > sequences are transactional, &c., is to eliminate all the concurrency
> > issues that might arise.  Adding a trigger or any other such
> > functionality is just a recipe for concurrency costs.
>
> True... so what's a good way of ensuring we get an overall win here?
> i.e. Reducing the total cost from finding the latest sequence number
> with each sync, *more* than the overhead involved from adding some
> mechanism to do it.

Andrew is going to need to say a little more before it's clear to me he's at 
all justified in calling sequence triggers a terrible idea.  He mistated 
the facts; sequences are NOT transactional (i.e., they're not rolled back).  
Maybe that's just a typo on his part, I don't know.  He seems to presume 
that any sequence trigger solution must entail that they be done inside a 
transaction (thus the "concurrency costs"); I don't share that presumption.  
If sequence values can be changed regardless of a rollback, then a 
notification regardless of rollback seems perfectly in order.  There may be 
other reasons, but...  He asserts the concurrency costs outweigh the 
benefits, but doesn't say why those costs are required nor does he give any 
data to support that claim, shortly after acknowledging the potentially 
significant cost on the other side of the cost-benefit ledger, polling.  
There is just a bit too much presumption here about a solution that hasn't 
been designed.  Polling vs. asyncronous notification is a classical 
software problem, and fundamentally, that is all this is; asyncronous 
notification is the performance answer to inefficient polling.  How exactly 
that's implemented is another question altogether.  Maybe it can't be done 
for other reasons (too hard to code, nobody who knows how to do it cares or 
wants to do it, etc).  But fundamentally, async notification is very likely 
the answer to the polling inefficiencies in one form or another.

Ed