From: "Robert Comer" 

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