Re: Allowing Oracle transactions to span client processes

ben_ml_at_hotmail.com (Ben) wrote in message news:<a62a8d2a.0309041254.eb7cbd3_at_posting.google.com>...
> Hi all.
>
> I hope I'm not sending this to an inappropriate group (but I reckon
> some people here will have some suggestions to help me).
>
> We have a fairly large system consisting of multiple applications
> (running on Windows and via a browser). These apps are implemented in
> various languages (C++, Java and VB). They all access a single
> central Oracle database.
>
> I want to be able to do work on the database from multiple processes
> and have them all commit as a single transaction.
>
> I've spent some time researching Transaction Managers and the like,
> and it seems to me that these might be overkill (they are pretty
> expensive and my company can't really afford to buy Tuxedo or
> similar). Most distributed transaction discussions seem to be
> focussed on one application updating multiple databases, whereas what
> I want is the opposite: updating one database (and a *known* RDBMS at
> that!) from multiple processes.
>
> One process will always 'control' the transaction (i.e. it is
> responsible for starting a transaction, calling other processes and
> then commiting or rolling back the transaction).
>
> I'm hoping that the Oracle RDMS has some nifty way of doing this
> (we're currently using 8.1.7 but we'll soon be on 9)?
>
> Alternatively, if I do need a TM/TPM can I get something relatively
> cheap to deploy since my requirements are pretty specific?
>
> Best regards
> Ben

Ben, there is no nifty feature to allow this. You will either have to buy a transaction manager or write a simple one.

You could have all your programs communicate with one program that actually performs all the updates via sockets or other communication features. You could make use of Oracle features such as dbms_alert and dbms_pipe to pass the data to the "transaction manager" Depending on exactly what you need to do you might be able to use a packaged set of routines and a holding table to collect data from various sources, associate the rows into units of work, identify the associated rows with a application "transaction" number, process the associated rows, and indicate success or failure to the various programs

But whatever you do you will have to do it manage it using Oracle's standard transaction management logic.

HTH -- Mark D Powell -- Received on Thu Sep 04 2003 - 20:10:03 CDT