db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Senn <will_s...@comcast.net>
Subject Re: I need some advice to choose database for an upcomming job
Date Wed, 09 Nov 2005 15:59:45 GMT

Michael said:

>> Will said:
>> However, that being said, my 2 cents is that it's totally nuts to commit
>> anything after an error, unless you don't care that your datastore is in
>> an unknown state (you being the database vendor). The argument that the
>> app developer might want it that way... sheesh harkens back to the days
>> of writing linear incongruent pseudo random number generators using
>> BASIC's integer overflow characteristics... Cool, but infinitely
>> frightening (non-portable, monster-unmaintainable) at the same time.
>> -Will
> I don't think that anyone is suggesting that.

Upon a reread, I see the error of my ways. The premise was that the 
client disconnected while the transaction was active. To commit or not 
to commit, that is the question... I can see it both ways, if the 
transaction was completely transmitted to the database, what relevance 
the client connection? It might be nice if you could resume a broken 
connection, then it'd be up to the application (or network layer) to 
maintain connectivity and resume broken connections and restore session 
state. In the absence of session resumption... If you don't do atomic 
commits... etc... It'd be a real bummer to open a transaction, get 
disconnected and not know what exactly occurred in the db...



> In further thought of my suggestion, I guess the database vendors would have 
> to do some work. Considering what I am thinking would force them to rethink 
> what is meant by a connection relative to a transaction, and how to allow for 
> multiple non-nested concurrent transactions to occur within the same 
> connection context.
> But again, I don't think that its going to be rocket science.

View raw message