On Wed, Aug 6, 2008 at 12:23 PM, Bill Karwin <[EMAIL PROTECTED]> wrote:
> > > > Philip G wrote: > > > > As for using lastSequenceId(), bad mojo. Using Zend_Db's default > > auto-commit > > settings, it's extremely easy to get sequence ids crossed during heavy > > loads, and thus causing all sorts of problems. > > > > I'm not sure I understand this statement. > > I'm pretty sure CURRVAL is limited to the scope of the current database > session; that's the only way it would be useful. That is, if I generate a > value 1234 with NEXTVAL, then CURRVAL will continue to report 1234 to me > repeatedly during my session, even if you continue to use NEXTVAL to > advance > the sequence in your session. CURRVAL will report different numbers; it's > always the number we each last generated in our respective sessions. > > Also, sequences are not affected by transactions. You cannot roll back a > call to NEXTVAL and "return" a value to the sequence. Also if I generate a > value 1234, then you generate a value, you will get 1235 regardless of > whether I have committed or not, and regardless of the transaction > isolation > mode either of us are using. Sequences must ignore transaction scope, in > order to maintain uniqueness. > > But perhaps there's something else that I don't know about your situation. > I'm curious to hear about it, since I'm not an Oracle expert specifically. > > As I know it, sequences aren't affected by your transactions nor are they limited to your current session. Unless .NEXTVAL goes outside of your session to grab the next id, leaving .CURRVAL in the current session only, I don't see how .CURRVAL wouldn't be affected by somebody else's NEXTVAL nor do I see how NEXTVAL wouldn't insure somebody else's NEXTVAL gets the next number after yours. The way I see it, CURRVAL and NEXTVAL would be stateless (I was mistake about the auto-commit requirement. ha), that way there isn't any numerical over laps between mutiple sessions altering the sequence value. As with you, I could be mistaken to. I'm by no means a DBA. I know Oracle only from limited exposure writing stored procs back in the day. --- Philip [EMAIL PROTECTED] http://www.gpcentre.net/
