From: "Robert Comer" 

> 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.

I have no problem with that concept.

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

Yep, that can be a problem.

- Bob Comer



"Ellen K."  wrote in message
news:8t3r81l1ln32pg5dd3jp992l13gv0c5rl3{at}4ax.com...
> 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