List:General Discussion« Previous MessageNext Message »
From:Matt Davies Date:January 6 2004 3:10pm
Subject:Re: Re[2]: transaction support
View as plain text  
Quoting DeBug <debug@stripped>:

> >>[MySQL]
> >>2: WITHDRAW $50 from account 32146.
> >>3: DEPOSIT $50 into account 12345.
> >>4: LOG transfer (date/time/teller/etc...) for auditing.
> DK> It depends why step 3 failed.
> DK> If you want to rollback the transaction to the beginning on any error,
> DK> you simply use an 'on error' statement in VB to trap the error, and send
> DK> a rollback command when the error is detected.
> And what if the server lost connection with client computer ?
> there must be automatic rollback after certain 'time-out' period
> Data integrity logic should be ensured by client application (when to
> call 'start transaction' and when to call 'commit'), the server task is to
> ensure that logic - i.e. that at any given moment users see the
> database in integrity state and not at some point within transaction
> processing.
> If user has not commited transaction the database integrity state is
> still at the point before start transaction was called.

My $0.02

I have to disagree - especially when money is involved. To have the client
define, check data integrity, and manipulate data in the database is just
asking for trouble. Call me paranoid, but to trust a client in a non-secure
environment to directly access and manipulate the database is just asking for a
reverse-engineered attack against the database where the data will be
compromised. At the very least, you are sending out database connectivity
information out with the client that can be stolen and used to access the

Given the means and the business necessity, I feel that having some sort of
middleware on a secured server to validate data and communicate with the
database is a much more secure methodology. This is a trivial piece of
middleware to write, but can add a much needed layer of security to
transactions. Let the secure server hosted middleware host the database
connections and let the client talk to the middleware. 

> Not user but server is responsible for rolling back not commited
> transactions, user can only help relief the server from major part of this
> problem by trying to
> rollback as many failed transactions as he can. however user cannot be
> responsible for rolling back all the transactions
> -- 
> MySQL General Mailing List
> For list archives:
> To unsubscribe:

transaction supportBryan Koschmann - GKT6 Jan
  • Re: transaction supportDaniel Kasak6 Jan
  • RE: transaction supportCraig Vincent6 Jan
    • RE: transaction supportBryan Koschmann - GKT6 Jan
      • Re: transaction supportMichael D Schleif6 Jan
      • Re: transaction supportDaniel Kasak6 Jan
        • Re[2]: transaction supportDeBug6 Jan
          • Re[3]: transaction supportDeBug6 Jan
          • Re: Re[2]: transaction supportMatt Davies6 Jan
  • Re: transaction supportEd Leafe6 Jan
  • Re: transaction supportMorten Gulbrandsen6 Jan
    • Re: transaction supportJochem van Dieten6 Jan
  • Re: transaction supportPeterWR6 Jan
    • RE: transaction supportPeter Lovatt6 Jan
  • Re: transaction supportrobert_rowe6 Jan
  • Re: transaction supportPatrick Shoaf6 Jan
RE: transaction supportDuane Needham6 Jan
  • RE: transaction supportBryan Koschmann - GKT17 Jan
    • RE: transaction supportChris Nolan17 Jan
      • RE: transaction supportBryan Koschmann - GKT20 Jan