Doing "set transaction read only" on Oracle has additional side-effects
besides making the connection unable to write: it switches the read
consistency level from per-statement (the default) to per-transaction.
This effectively freezing the connection in time, allowing multiple
queries to be executed against changing data to "match up".
It might surprise someone who thought they were just getting a read-only
connection, especially if they're polling the database for changes and
wanted to be lighter weight. It consumes more resources, not less,
since Oracle must reverse out all changes since your "set trans.."
statement with each query, and might result in a "snapshot too old" error.
I don't know if/how other databases implement this feature, and give it
such a possibly misleading name. Does anyone else?
Scott Smith
Tim Bunce wrote:
I've just added this to the DBI docs:
=item C<ReadOnly> (boolean, inherited)
An application can set the C<ReadOnly> attribute of a handle to a true value to
indicate that it will not be attempting to make any changes (insert, delete,
update etc) using that handle or any children of it.
If the driver can make the handle truely read-only (by issing a statement like
"C<set transaction read only>" as needed, for example) then it should.
Otherwise the attribute is simply advisory.
A driver can set the C<ReadOnly> attribute itself to indicate that the data it
is connected to cannot be changed for some reason.
Library modules and proxy drivers can use the attribute to influence their
behavior.
For example, the DBD::Gofer driver considers the C<ReadOnly> attribute when
making a decison about whether to retry an operation that failed.
=cut
Any thoughts?
Tim.
