Rick Welykochy wrote:
> On Tue, 21 Mar 2000, Richard Hayes wrote:
>
> > MySQL is small, fast and stable. But it is not a full blown database
> > system such as IBM DB2 etc
> >
> > It can not do 'rollbacks' but since neither can the the web, who
> > cares???
>
> Great logic there. It can not do 'rollbacks' but since neither can
> <insert irrelevant item>, who cares??
>
> Rollbacks are required for several reasons, two important ones
> being the following:
>
> (1) if a lengthy transaction-based process (which is possible from ONE
> single, stateless web hit) fails partway through, it is quite messy
> to undo what has been done so far without rollback.
>
> (2) in a multi-tasking environment (which is common with MANY stateless
> single web hits occurring simultaneously), a complete transaction
> must be commited as an atomic unit, otherwise, interference from
> other 'piecemeal' transaction bits can cause confusion and
> database inconsistencies, e.g. see the example posted on this
> thread yesterday regarding auto-incrementing keys/fields.
>
> I've been contemplating implementing a rollback and commit
> feature for MySQL using some perl classes, but it'll be Alotta Verk.
> And it will never reach the efficiency of a DBMS that provides
> this feature, since table-wide locking will probably be required.
>
> -rickw
>
> --
> Rick Welykochy || Praxis Services
>
> --
> SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
> To unsubscribe send email to [EMAIL PROTECTED] with
> unsubscribe in the text
You are still going to have problems. If the user leaves the website half
through the transaction, how are going to know that you need to a
rollback. The trick is to make the http request atomic, that is all the
information that is needed for the transaction is carried as parameters
within your cgi script. When the user decides they are finished all the
information you need to update the update the database comes in the one
submit. The design of your database can also help, MySql garuntees that
certain operations (short of catastrophic failure, in which case rollback
isn't going to help) will always succeed. eg. Autonumbered columns will
always return a value. If you RTFM the MySql manual they have a section
on how to avoid commits and rollbacks. Implementing your own
commit/rollback strategy seems a bit extreme. I hope this of some help.
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
