Transaction Engine

Christopher Browne cbbrowne@mail.hex.net
Fri, 05 Jan 2001 08:46:27 -0600


On Fri, 29 Dec 2000 09:24:40 EST, the world broke into rejoicing as
David Merrill <dmerrill@lupercalia.net>  said:
> On Fri, Dec 29, 2000 at 02:46:51AM -0600, linas@linas.org wrote:
> > It's been rumoured that cbbrowne@ntlug.org said:
> > > 
> > > It should be clear why Transaction engine and DB engine should stay close
;
> > > they will need to communicate quite a lot of data in order to negotiate
> > > the parts that are to be submitted to the GUI.  A "for instance" would
> > > be that if the DB does not support computing sums/balances internally,
> > > the transaction engine will need to do so, and will have to talk heavily
> > > with DB.
> > 
> > I had always hoped/envisioned that the engine could run both in the server
> > *and* the client.  In the client, it provides a convenient programming
> > API, and a data cache.  In the server, it provides transactional
> > capabilities & functions (and a convenient programng API).
> 
> What exactly is this "transaction engine"? All transactions can be
> handled, and should be handled, within the db itself. The engine will
> need to be aware of this functionality, but it needn't do anything to
> make it happen. Any other approach is a mistake and a recipe for
> disaster.

There will be a _bunch_ of things that will _not_ be handled "within
the DB."

Notably:
a) Balance management [the thing of keeping track of daily balances,
   or perhaps based on some other granularity];

b) Event management; telling GUIs when [say] a balance on which the
   present screen depends, or when one of the transactions on screen
   have changed.

Certainly it is important for the DB to manage the checkpoint:
commit-versus-rollback aspect of "transactions."

But the DB won't be managing all aspects of balances and events.
That needs to be handled by what seems best termed as a "transaction
manager;" I'm not speaking of commit/rollback, but rather of having
a server program that manages the Stuff That Happens when you update
a transaction.  Two things would include:
 - Updating balances
 - Notifying any bits of the system that need to know when a particular
   transaction is updated.  Such as letting the GUI know to display new
   values.

Note that transaction processing monitors like Tuxedo, Encina, and
"message managers" like MQSeries get used even in the presence of
the most sophisticated DBMSes in order to improve reliability and
performance.  I expect that this is true here...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
Should vegetarians eat animal crackers?