Orchid XP v7 wrote:
> I was expecting great things. Maybe too great. What I actually found is 
> that by default "commit" and "rollback" are no-op, and transaction 
> handling is an "optional feature" that you have to explicitly enable.

Honestly, of the 30 or so tables currently in my application, there's 
about 5 that need transactional consistency. I don't need it in the 
debugging logs. I don't need it in the (equivalent of) web access logs. 
I don't need it in the tables that's collecting the real-time feeds off 
the various partners, nor off the custom hardware. Those are all 
append-only (for the most part) tables.

But where I need it, I turn it on, and take the penalty of speed over 
correctness.  Enforcing transactions is high overhead if you don't need 
it. If all your table write-accesses are to a single row, why would you 
want to lock things?

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message