From: "Paul Ranson" 

When should the database do a rollback? When the object that decided not to
commit gets garbage collected?

In C++ it's natural to use some variation on this style,

void ApplySomeDatabaseStuff ( Database db ) {
   Transaction t ( db ) ;
   if ( FAILED ( SomeDBOperation ( db )))
      return ;
   if ( FAILED ( SomeOtherDBOperation ( db )))
      return ;
   t.Commit () ;
}

when 'Transaction' goes out of scope, if no commit has been performed it
calls for a rollback. Every path through the function that involves a
failure gets rolled back with no explicit (and therefore forgettable)
action from the programmer. If you use exceptions the code gets cleaner at
this level.

FWIW I've seen apps that don't leak, never actually have that much memory
allocated but do compromise the OS regardless due to the pattern of usage.
A GC wouldn't necessarily save you from this sort of pathological
situation. I like GC for some applications because it can substantially
improve performance, I don't find the argument that incompetent programmers
will leak less very convincing.

Paul

"Robert Comer"  wrote in message
news:428aa288$1{at}w3.nls.net...
>> Object lifetime isn't the same thing as memory management. Consider a
>> database transaction, or any resource lock. Why you want your
>> underpressure, tired etc programmers time after time having to do their
>> own rollbacks or releases is beyond me.
>
> Why would you do that, the DB should be able to handle the rollbacks.
>
>> OTOH garbage collection isn't a panacea, however you manage memory if
>> your programmers don't know what they're doing you're heading for
>> trouble.
>
> At least you get apps that wouldn't compromise the OS as easily as C++ for
> those tired programmers from your first paragraph.
>
> - Bob Comer
>
>

--- BBBS/NT v4.01 Flag-5