From: Ellen K. 

It was an analogy.  If you want your database to do a transaction you have
to BEGIN TRANSACTION before it starts doing stuff and COMMIT TRANSACTION
when it's done.  ROLLBACK TRANSACTION goes in your error handlers that come
after each piece, so that if one piece fails, all the pieces that came
before get rolled back.

And GC means garbage collection, one problem with which is that you never
know when the garbage collector is going to do its thing.

On Wed, 18 May 2005 09:05:05 -0400, "Robert Comer"
 wrote in message
:

>Okay, I see what you're saying.
>
>I'm just learning it now and haven't got to any serious db access yet, so
>forgive my current ignorance.  I haven't got up to the part with serious DB
>access yet..
>
>So .NET (whatever language) wouldn't do the same thing when a transaction
>goes out of scope?  (without a explicit commit or a rollback)   What happens
>in that case, seems like it would leave a hanging lock on the DB and you'd
>eventually really fubar something up.  I'm not sure I understand why that
>would be...
>
>I personally haven't had trouble remembering the commit or rollback, but it
>could be a style thing...
>
>> 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.
>
>Of course, that's why I said "as easily". 
>
>>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.
>
>"GC"?
>
>- Bob Comer
>
>
>
>
>"Paul Ranson"  wrote in message
news:428b261f{at}w3.nls.net...
>> 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