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...
Later,
Will
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.
