Re: Proposal for new $h-{ReadOnly} attribute
Any thoughts? Amen: Most of the perl I use only does reads and the readonly locking could be a big savings. -- Steven Lembark 85-09 90th Street Workhorse Computing Woodhaven, NY 11421 [EMAIL PROTECTED] +1 888 359 3508
Re: Proposal for new $h-{ReadOnly} attribute
On Wed, May 09, 2007 at 02:33:23PM -0400, Steven Lembark wrote: Any thoughts? Amen: Most of the perl I use only does reads and the readonly locking could be a big savings. I trust you'll be sending patches to the authors of the drivers you're using... :) Tim.
Re: Proposal for new $h-{ReadOnly} attribute
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 CReadOnly (boolean, inherited) An application can set the CReadOnly 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 Cset transaction read only as needed, for example) then it should. Otherwise the attribute is simply advisory. A driver can set the CReadOnly 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 CReadOnly attribute when making a decison about whether to retry an operation that failed. =cut Any thoughts? Tim.
Re: Proposal for new $h-{ReadOnly} attribute
On Fri, May 04, 2007 at 08:15:53AM -0500, Scott Smith wrote: 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. s/freezing the connection in time/freezing the transaction in time/ ? So effectively no change if AutoCommit is on? If AutoCommit is off, then the effect lasts until the next commit/rollback, but an app that's read only might not be doing any commits. I agree that's an issue. 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. That's certainly a good argument for the ReadOnly attribute not doing a set transaction read only on Oracle. I'll tweak the docs. It's also an argument in favor of ReadOnly not being a simple boolean. Thanks. Tim. p.s. You're *just* in time for 1.55. 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 CReadOnly (boolean, inherited) An application can set the CReadOnly 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 Cset transaction read only as needed, for example) then it should. Otherwise the attribute is simply advisory. A driver can set the CReadOnly 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 CReadOnly attribute when making a decison about whether to retry an operation that failed. =cut Any thoughts? Tim.
Re: Proposal for new $h-{ReadOnly} attribute
Tim Bunce wrote: On Fri, May 04, 2007 at 08:15:53AM -0500, Scott Smith wrote: 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. s/freezing the connection in time/freezing the transaction in time/ ? Good point, speaking of small differences which make a difference. So effectively no change if AutoCommit is on? If AutoCommit is off, then the effect lasts until the next commit/rollback, but an app that's read only might not be doing any commits. Wow. I hadn't thought of using commit/rollback to intentionally select when to bump the time point forward. I agree that's an issue. 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. That's certainly a good argument for the ReadOnly attribute not doing a set transaction read only on Oracle. I'll tweak the docs. It's also an argument in favor of ReadOnly not being a simple boolean. Thanks. Tim. p.s. You're *just* in time for 1.55. Yeah. Sorry to reply four days late... Scott 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 CReadOnly (boolean, inherited) An application can set the CReadOnly 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 Cset transaction read only as needed, for example) then it should. Otherwise the attribute is simply advisory. A driver can set the CReadOnly 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 CReadOnly attribute when making a decison about whether to retry an operation that failed. =cut Any thoughts? Tim.
Re: Proposal for new $h-{ReadOnly} attribute
On Tue, May 01, 2007 at 10:43:40AM +0200, H.Merijn Brand wrote: On Mon, 30 Apr 2007 14:56:37 +0100, Tim Bunce [EMAIL PROTECTED] wrote: I've just added this to the DBI docs: =item CReadOnly (boolean, inherited) An application can set the CReadOnly 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 s/issing/issuing/ ? Yes, and s/truely/truly/ :) Cset transaction read only as needed, for example) then it should. Otherwise the attribute is simply advisory. A driver can set the CReadOnly 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 CReadOnly attribute when making a decison about whether to retry an operation that failed. =cut Is it inherited? Yeap. Do statement handles from a ReadOnly driver handle get the same attribute passed? If so: useful. I'd like to see that extended to be able to allow dirty reads or no-lock reads, whatever the database allows. Those are too database specific to warrant adding to the DBI (and not really related to to the role of the ReadOnly attribute). Drivers can always offer private ways to do such things. Tim.
Re: Proposal for new $h-{ReadOnly} attribute
On 4/30/07, Tim Bunce [EMAIL PROTECTED] wrote: If the driver can make the handle truely read-only (by issing a statement like Cset transaction read only as needed, for example) then it should. Otherwise the attribute is simply advisory. For reading the value, I agree. I'd like to see a third value when writing. This third value could mean Make it read-only, if you can, otherwise throw an exception. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal.
Re: Proposal for new $h-{ReadOnly} attribute
On Apr 30, 2007, at 6:56 AM, Tim Bunce wrote: I've just added this to the DBI docs: =item CReadOnly (boolean, inherited) I like it! Another use case is in typical replicated setups with some write nodes and some read-only nodes. - ask -- http://develooper.com/ - http://askask.com/
Re: Proposal for new $h-{ReadOnly} attribute
On Mon, Apr 30, 2007 at 04:39:05PM +0200, Jochen Wiedmann wrote: On 4/30/07, Tim Bunce [EMAIL PROTECTED] wrote: If the driver can make the handle truely read-only (by issing a statement like Cset transaction read only as needed, for example) then it should. Otherwise the attribute is simply advisory. For reading the value, I agree. I'd like to see a third value when writing. This third value could mean Make it read-only, if you can, otherwise throw an exception. I can see some value in it, I'm just not sure it's worth it. There's the question of picking 'magic value' to represent it. There's also the issue of how different databases and drivers may differ in the degree to which they can support it. We can return to it later. For now I'm happy to just document it as a boolean and that only 0 and 1 should be used. Tim.
