>>>>> On 20 Dec 91 19:25:37 GMT, jfr@locus.com (Jon Rosen) said:

> In article <CIMSHOP!DAVIDM.91Dec18105111@uunet.UU.NET>
> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

>> Consider an object-oriented model of a relational database system's
>> transaction handling.  A transaction wraps a series of database operations.
>> When the transaction is done, the results of the database operations is
>> "computed" and error conditions might be detected (integrity violations,
>> etc.).  For modeling purposes, it seemed appropriate to model the "begin
>> transaction" and "end transaction" of a relational database as a
>> constructor and destructor on a Transaction class.  The thing is, though,
>> that both the constructor and destructor may run into "exceptional"
>> conditions (for instance, the constructor may fail to establish the
>> database connection and the destructor may find integrity violations).
>> Therefore, is modeling a transaction as a class an appropriate thing to do?

> Why not just instantiate a Transaction object at BT time and then have a
> normal BT method invoked to actually start the transaction.  Same with ET.

To me, it seemed that mirroring BT/ET by CTOR/DTOR allowed for more "provably
correct" programming in that disallowing a Transaction to be allocated to the
heap would mean that methods dealing with the Transaction object would be the
scope of a transaction.  For future reuse of code, this seemed to be a Good
Thing in that people would know what they are dealing with when calling a
method.  With a Transaction object that allowed nestable transactions, users
could reuse Transaction derivatives in new, larger transactions without too
much concern for the coupling of Transaction objects.

> It may even be necessary for the transaction object to remain instantiated
> after ET time to deal with things like sending messages to the user (or
> other objects) concerning the success or failure of the transaction.

This is where exceptions would come in.  Also, in an exception model, would
your approach leave uncommitted transactions (at the RDBMS level) lying
around?

> The transaction should not destroy itself until it is totally finished with
> all of its work and I would not think the destructor is the appropriate
> place to be concentrating that kind of code (which could even involve some
> "long-running" activities).

I guess this depends on how you define "long-running" activities and what
controls (scopes?) them.  Nesting transactions allows for little transactions
to be grouped into bigger (longer running) transactions, but it requires
understanding of what types of transactions can be nested inside other
transactions (for instance, an update transaction cannot go in a read-only
transaction).  Nesting means that these little transactions consider their
work to be done when they are destroyed, but the Transaction object may have
more context knowledge (it is inside another Transaction) and not commit the
work of the Transaction (leaving it to the parent Transaction to decide).

> Better yet, use a system that has garbage collection and let it destroy the
> objects automatically.

Interesting point, though.  Would garbage collection cause problem in a system
where the destruction of an object might have consequences beyond cleaning up
memory for an object (like the effect a Transaction object would have on the
RDBMS)?  I don't think I'd want a garbarge collector involved in this case as
it would (potentially) mean that the RDBMS is locked until the Transaction
object is garbage collected.
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <CIMSHOP!DAVIDM.91Dec18105111@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>I have not yet used a C++ compiler that has exception handling, so understand
>where I'm coming from.  First I have some questions about exception handling
>and then I'll explain why I'm asking the questions.
>
>Questions:
>
>1. Can a destructor 'throw' an exception?
>2. If so, how do you 'try' an automatic destructor and 'catch' its exceptions?
>3. If not, why?
>
>Problem Model:
>
>Consider an object-oriented model of a relational database system's
>transaction handling.  A transaction wraps a series of database operations.
>When the transaction is done, the results of the database operations is
>"computed" and error conditions might be detected (integrity violations,
>etc.).   For modeling purposes, it seemed appropriate to model the "begin
>transaction" and "end transaction" of a relational database as a constructor
>and destructor on a Transaction class.  The thing is, though, that both the
>constructor and destructor may run into "exceptional" conditions (for
>instance, the constructor may fail to establish the database connection and
>the destructor may find integrity violations).  Therefore, is modeling a
>transaction as a class an appropriate thing to do?

  I think that modelling a transaction as a class is sound.  The problem
  may be with the idea of using the begin/end transaction logical
  concepts in parallel with the constructor/destructor physical object
  capabilities of C++.  Or at least the destructor, anyway.

  Why not just instantiate a Transaction object at BT time and then
  have a normal BT method invoked to actually start the transaction.
  Same with ET.  It may even be necessary for the transaction object
  to remain instantiated after ET time to deal with things like
  sending messages to the user (or other objects) concerning the
  success or failure of the transaction.  The transaction should not
  destroy itself until it is totally finished with all of its work
  and I would not think the destructor is the appropriate place to
  be concentrating that kind of code (which could even involve some
  "long-running" activities).  Better yet, use a system that has
  garbage collection and let it destroy the objects automatically.
  OOPs (pun intended :o)  There I go again promoting Smalltalk :-)
  Sorry :-)

  Jon Rosen
  ------------------------------------------------------------
  From The Devil's DP Dictionary by Stan Kelly Bootle:

  Database Management System [Origin: Data + Latin basus "low,
  mean, vile, menial, degrading, counterfeit."] A complex set
  of interrelational data structures allowing data to be lost
  in many convenient sequences while retaining a complete re-
  cord of the logical relations between the missing items.
  ------------------------------------------------------------