Re: When to Commit?

From: Ed Prochak <ed.prochak_at_magicinterface.com>
Date: Fri, 08 Jul 2005 23:20:26 -0400
Message-ID: <1ad6b$42cf406e$471d7821$25225@ALLTEL.NET>

joel-garry_at_home.com wrote:

>>Billing is seldom an OLTP process.

>
>
> Wow, I guess I work on a rare system. Invoices are generated as items
> are shipped. (The invoice printing is pseudobatch, though, since that
> is done by different department).
>
> Of course, there is a lot about the system that would be considered
> poor design, as it is one of those "database-independent" thingies.
>
> So I agree with Daniel and Sybrand, poor design, but agree with Mark
> about the concurrency thing. In fact, the system can choke on locks if
> it hits concurrency or wait issues - it gives the user the choice to
> wait or bail (like if a warehouse peon goes to lunch in the middle of
> updating inventory and someone else needs that spot - easily resolved
> with Oracle lock manager). Although, I actually got a ORA-60 last
> week. Scratched my head, until I noticed the trace file has osuser
> id's, and I was able to determine someone hit a lock (this was on a
> different system than the above), called up someone else who then ran
> the same single-user batch update while the first was still locked.
> Sheesh. But while technically "bad," the design has been mostly wrung
> out and generally works well, and gives all source code. I've
> certainly seen worse in all those areas. Perhaps the worst part is it
> is so easy to customize the design tends to deteriorate towards non-R
> business processes. Those darn business people!
>
> jg
> --
> @home.com is bogus.
> Medicines equivalent of defrag myth: http://msnbc.msn.com/id/7722862/
>

I should have been clearer and said "monthly billing" rather than just billing. (the comment was in context of telecom billing) Billing and invoicing for me currently have less than normal meaning. Creating an invoice is certainly somthing done at point of sale. I've been thinking of Billing separately because of the POS system I work on seldom involves cash tranactions. An Invoice is generated at the sale and then the billing statement is sent later to the company (that billing statement might be an EDI file with data from lots of invoices).

We have the locking issue with Stock tables also, BUT it never stops the invoice from being printed. The stock update process just WAITs until the lock has been freed. (And this is in UNIFY Data Server DBMS which doesn't have ORACLE's nice concurrency model, it is hard locks and occasional dirty reads.) I cannot imagine holding up a printout, especially an invoice. My first year here was in dealing with this issue and I now have it so that short of a a system crash or users trying to payout right at the nightly cleanup (when all users are automatically logged off for a couple minutes) we no longer have any of what we call ghost work orders.

So as much as I respect your opinion, Joel, I still say the concurrency issue about generating last month's bill holding up updating this month's data that Mark raised is false. (or as Car Talk's Tom would say: BoooGUS!) It is BAD design.

  On the minor rant side >> Hey I DO KNOW about "Those darn business people!" The marketting manager here is know on occasion to ask us to change some process to do exactly the opposite of what he requested a year earlier. (Being able to do Rapid Application Development can be a curse sometimes!) We manage to keep his requests under control most of the time.

-- 
Ed Prochak
running    http://www.faqs.org/faqs/running-faq/
netiquette http://www.psg.com/emily.html
--
"Two roads diverged in a wood and I
I took the one less travelled by
and that has made all the difference."
robert frost

Received on Fri Jul 08 2005 - 22:20:26 CDT