Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RFC on Fitch & Mather Sample

Re: RFC on Fitch & Mather Sample

From: Steve Jorgensen <nospam_at_nospam.com>
Date: Wed, 16 Jun 1999 18:10:28 -0700
Message-ID: <yVX93.31995$SN3.13010812@news1.teleport.com>


huh wrote in message <7k7oag$2v3s$1_at_ns.felk.cvut.cz>...
>Hello,

 <snip>
>What is the difference between putting rolback into the trigger (on a
server)
>instead of using an exception mechanism in a client (pros and cons)?
 <snip>

I strongly support executing atomic transaction entirely withing single server-side batches. The batches can etiher be submitted by the client in real-time or be encapsulated in server stored procedures called by the client. For error trapping to be done with this design, it cannot be done by the client, so it must be written into the batch, possibly aided by the use of triggers.

Of course complete or partial prechecking of data should also be done by the client when practical to reduce the use of network bandwidth and server resources to make clearly invalid requests.

The following are some reasons for starting and committing a transaction within the same server-side batch.

  1. Server-side locks are held until a transaction completes, and interaction between client and server during a batch will usually cause a transaction to remain open for many times longer than it would if executed completely on the server.
  2. A client may experience an error between the start and finish of the transaction that is too severe (or not handled well enough) to allow the transaction to be completed by the client without intervention. This may leave locks open that can stop other users from continuing to work. If the task has to be cancelled from the server, a partially completed transaction may be rolled forward, not back leaving data in an inconsistent state.
  3. Connection protocol faults can cause disconnections during client-driven transactions that don't allow the transaction to be completed without restarting the server system.
Received on Wed Jun 16 1999 - 20:10:28 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US