On Sun, 2011-12-18 at 14:05 +1100, Chris Angelico wrote:
> On Sun, Dec 18, 2011 at 2:02 PM, Chris Travers <chris.travers@gmail.com> wrote:
> > I do not believe there are performance penalties for either. All
> > commit or rollback does is determine visibility of changes made.
>
> Thanks. (And thanks for the incredibly quick response!)
>
> My framework has a "read-only mode" (determined by user-level access),
> in which it begins a read-only transaction. At the end of it, I
> currently have it rolling the transaction back (to make absolutely
> sure that no changes will be made), but was concerned that this might
> place unnecessary load on the system. I'll stick with rolling back,
> since it's not going to hurt!
>
> Chris Angelico
>
The actual rollback won't hurt as long as you have not made any
modificatons to any records. But opening the transaction could have side
effects for other processes that want to modiy the records that you want
to protect in your read-only transaction.
How about using a databaseuser that has it's create/update/delete rights
revoked? That will cause an error if the supposedly read-only routine
does try to change data.
