If your transaction are only 1 query deep, why use them at all? An
individual query is already atomic, regardless of table type/server
- michael dkyman
On 9/17/07, Robert DiFalco <rdifalco@stripped> wrote:
> While it is functionally equivalent I wonder if it the code paths taken
> are the same. I suppose for both commit and rollback mysql would have to
> look for any pending work, if there were none both would do nothing.
> That's what makes me think that there is probably no performance
> difference between the two. I ask this because my programmers like to do
> con = ...
> queryOnlyWith( con );
> And I wanted to make sure that this would perform the same and act the
> same as issuing a commit (unless there was an exception but I'm not
> analyzing that case).
> -----Original Message-----
> From: Baron Schwartz [mailto:baron@stripped]
> Sent: Monday, September 17, 2007 2:36 PM
> To: Robert DiFalco
> Cc: mysql@stripped
> Subject: Re: Rollback on a Transaction with No Updates
> Robert DiFalco wrote:
> > Is there any difference between calling rollback or commit on a
> > transaction that did not alter data? For example, not a read-only
> > transaction but a transaction that only performed read-only selects.
> > Any difference in performance between calling rollback or commit? I
> > know they are functionally the same at the high level.
> The only thing I could think of was possibly rollback would leave open
> transaction and its read view if you are running in REPEATABLE READ
> isolation mode, whereas commit begins a new transaction and discards the
> read view. But I just tested that, and both commands start a new
> transaction and discard the read view.
> That's a long way of saying they are functionally equivalent as far as I
> know, as long as there are no changes to discard.
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1
- michael dykman
- All models are wrong. Some models are useful.