Re: Checking for uncommited transactions

Immo Landwerth wrote:

> Galen Boyer wrote:
>
> > No, what you should do is wait until the client has hit a submit
> > button and then do all of the DML and commit, as one single unit.
>
> That's what I wanted to say. But FC said this:
>
> > Hang on a minute, one can design a screen that contains two forms in
> > two different tabs. This screen is a "logical" unit, so, switching
> > from one tab to the other doesn't mean you have to commit or rollback.
> > You can defer the commit or rollback until you exit from the "main"
> > screen.
>
> This would mean that the end-user has too much control over the
> transaction. He opens the form, changes a lot of stuff (causes several
> inserts, updates or deletes) and commits when closes the form.
>
> > Your problem is that you allow client's modifications to take place
> > over a long time span (ie, allowing for think time during the
> > transaction). You need to keep all of the modifications in the app
> > until the modifications that define the transaction are ready to be
> > submitted. Until that time, no database modifications should be made.
>
> This is exactly what I said: Encapsulate the transcation in a logical
> unit. In my expierence the best way of doing so is an encapsulation in
> PL/SQL code on the server (package). Of course the code can also be
> sent from the client app. But keeping code in the server has many
> advantages. Transactional based code is allways one of the more
> important code passages and therefore it should be kept in the server.
> I know this doesn't improve the transaction it self.
>
> > Completely untrue. A transaction is a business rule. A business user
> > is one who enacts this rule. The application gives them the facility
> > to enact the rule.
>
> Correct. But don't give the user these three buttons: Insert, Commit
> and Rollback. According to Murphy's Law the user will neither press
> commit nor rollback until he has finished a two hour telephone call :)
>
> Do we share the same point?
>
> --
> Immo Landwerth - XP Pro - D5 Pro SP1 - XanaNews 1.14.1.1

And not with me either.

You can think of users as geniuses, average, or complete morons ... it doesn't much matter. The app is theirs, the business process is theirs, you are right that the code belongs in the back-end but the control belongs in the hands of the end-user. If they can't make the commit/rollback decision ... you as the developer definitely can not.

Daniel Morgan Received on Thu Mar 13 2003 - 00:49:54 CST